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ABSTRACT 


As  Increasing  data  processing  power  becomes  avallabla  at 
decreasing  east*  greater  numbers  of  nontechnical  personnel 
are  gaining  access  to  automated  systems  that  enhance  their 
productivity.  However,  the  sharp  distinction  between  each 
of  the  supoort  packages,  and  the  requirement  for  the  user  to 
become  familiar  with  different  models,  concents  and 
vocabularies  is  a  barrier  to  reaching  higher  effectiveness. 
The  premise  is  that  these  common  support  systems  have 
equivalent  functions  and  a  large  Intersection  of  operations 
that  can  be  integrated.  Xt  Is  tne  purpose  of  this  thesis  to 
study  a  Possible  Integrated  Application  software  system 
(IASS)  that  win  combine  the  needed  capabilities  l"to  a 
functional  system  and  present  the  user  with  e  single  date 
model  end  vocabulary  set.  The  date  model  which  Is  proposed 
for  use  by  the  TASS  is  the  relational  data  model,  since  It 
Is  universally  understandable,  and  has  a  robust  thaoretleal 
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I.  INTRODUCTION 


The  utilisation  of  eoaputors  in  aany  arm,  sueh  as 
parsonal  computing  or  offlea  and  manufacturing  automation, 
is  rapidly  expanding.  No  longer  is  their  use  belno 
relegated  to  sueport  personnel*  but  is  spreading  into  the 
rants  of  lower  and  middle  level  management.  The  majority  of 
sueh  users  are  non«eomputer  professionals  who  are  coming  to 
depend  on  the  computer  to  provide  a  supnort  capability  in 
the  accomplishment  of  their  primary  responsibilities. 

Over  the  pest  years,  numerous  software  packages  have 
been  made  available  to  support  a  broad  spectrum  of  users  in 
varying  environments.  Capabilities  such  as  word  processing, 
database  management,  modeling,  form  generation,  and 
electronic  mall  have  become  essential.  The  point  to  be  made 
is  that  the  original  purpose  of  introducing  the  computer  was 
to  increase  the  effectiveness  and  efficiency  of  the 
organization,  while  the  present  performance  of  eaeh  support 
package  is  satisfactory,  the  manner  in  which  they  are 
presented  to  the  user  is  not.  As  illustrated  in  Figure  1.1, 
eaeh  support  system  is  typically  disjoint  from  all  others, 
and  the  user  is  presented  with  differing  models,  command 
vocabularies,  and  operating  instructions.  This  nen- 
intogratad  combination  of  application  software  requires  e 
greet  deal  of  effort  on  tho  part  of  the  user  to  become 
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familiar  with  a  new  system  and  remember  it  along  with  tha 
other  systems  that  ara  utad, 

l  ■  l  l  ■  l 

m  m 

Figure  1.1  •  Disjoint  Support  Systams. 

What  is  needad  to  lneraase  productivity  Is  an  lntagrated 
system  that  combines  the  capabilities  of  the  supoort 
packages  into  a  system  which  presents  the  user  with  a 
single,  yet  easy,  conceptual  data  model  and  vocabulary  set. 
It  ts  such  a  system  that  Is  called  an  Integrated  Application 
Software  System  (TASS),  and  the  purpose  of  this  thesis  Is  to 
develop  a  design  for  Its  Implementation,  it  Is  Important  to 
emphasize  that  tha  IASS  is  not  built  around  tha  already 
existing  application  programs,  but  the  reverse.  Given  an 
TASS's  common  user  interface  and  conceptual  level,  the 
designer  will  evaluate  each  acolleatlon  and  design  a  new 
abbilcatlon  program  to  capitalize  on  the  IASS  capabilities. 

The  design  objectives  for  the  IASS  are* 

(1)  Ensure  a  high  degree  of  user  friendliness  and 
emphasize  simplicity. 


(2)  Minimize  the  Initial  and  aequlrad  usar  skill  level 
naeassary  to  gain  major  functional  usa  of  the  system, 

(3)  Minimise  the  learning  time  required  to  gain 
functional  usa  of  the  system, 

(4)  Present  a  looieal  interface  between  each  of  the 
XASS's  capabilities,  but  minimise  the  explicit  user 
navigation  between  them, 

(5)  Determine  the  largest  Intersection  of  functional 
eaoabllltles  for  the  Individual  application  proorams  and 
integrate  them  Into  a  common  conceptual  level. 

(6)  Develop  as  small  a  command  vocabulary  as  possible 
at  the  user  Interface,  ensure  that  these  commands  form  an 
intersection  of  the  application  program  commands,  and  are 
consistent  between  each  of  the  applications. 

(7)  Eliminate  the  dependence  on  user  proarammino  In 
order  to  use  the  system. 

(?)  Embody  the  notion  of  software  adaptivity  whereby  a 
user,  already  familiar  with  at  least  one  application  m  the 
XA3S,  can  learn  a  new  application  by  studying  only  the  small 
increment  of  new  commands  and  functions  that  are  specific  to 
the  new  application. 

(9)  Mew  applications,  not  originally  considered  in  the 
original  IASS,  are  implemented  by  adding  a  small  increment 
of  functions  and  commands  to  the  IASS, 

(10)  Allow  for  the  interaction  of  the  included 
applications  in  support  of  each  other. 
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While  the  IASS  cannot  b#  expected  to  completely 
integrate  tho  coparato  feature*  of  each  support  package,  It 
ean  strive  to  maximize  the  intersection  between  them.  Fiqure 
1.2  shows  a  simple  illustration,  in  Venn  Diagram  fora,  of  an 
IASS. 
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Fiqure  1.2  •  IASS  Support  Package  intersection. 

In  the  following  chapters  the  basis  of  an  IASS  design 
will  be  discussed.  Chapter  2  will  describe  a  selected  croup 
of  currently  successful  application  support  programs  that 
will  be  considered  for  integration  into  an  IASS.  Chapters  3 
and  4  win  eover  the  conceptual  level  of  the  iass  which  is 
invisible  to  the  user.  Chapter  3  discusses  a  common  data 
object  for  the  IASS,  and  Chapter  4  the  conceptual  level 
operations  allowed  on  it.  Chapter  5  covers  the  use  of  the 
conceptual  level  by  the  Included  application  programs. 
Chanter  4  covers  how  the  user  win  interface  to  the  IASS, 
Finally,  Chapter  7  presents  the  conclusions  that  ean  be  made 
from  this  United  study  of  an  IASS. 
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II.  DESCRIPTION  OF  SUPPORT  SYSTEMS 

In  order  to  demonstrate  the  applicability  of  an 
Integrated  Application  Software  System  (IASS)  and  Its 
conceptual  level  lnteoratlen  approach,  six  common  software 
applications  were  selected.  The  applications  were  chosen 
based  on  their  perceived  effect  in  suoeortina  an  office 
based  user, 

a.  Text  Editor 

b.  word  Processor 

c«  Relational  Database  Management  System 

d.  Electronic  Spread  Sheet 

e.  forms  Generator 

f.  Electronic  Mail 

As  a  ron-intearated  collection  of  application  software, 
each  of  these  packages  is  implemented  to  accomplish  a  set  of 
operations  on  a  specific  file  type,  and  the  set  of  included 
operators  is  tailored  for  that  type.  Commands  are  not 
usually  transferable  between  applications  and  the 
application  vocabulary  is  very  "baroque"  in  that  most  of  the 
operators  exist  as  a  matter  of  convenience  to  the  user.  Too 
often  it  is  a  very  small  percentage  of  the  overall 
vocabulary  that  is  used  over  ninety  percent  of  the  time.  The 
majority  of  users  only  learn  a  subset  of  the  vocabulary 
necessary  to  aeeoaollsh  the  essential  functions  of  the 
application  package,  and  disregard  tha  rest. 
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Representative  commercially  available  software  packages 
corresponding  to  the  six  selected  application  types  were 
reviewed  to  determine  the  nature  of  the  pertinent  file  types 
and  the  essential  functions  regulred  of  the  application.  The 
following  sections  win  present  the  results  of  this  review 
as  they  apply  to  each  application  package. 

A.  TEXT  EDITOR 

The  purpose  of  a  text  editor  is  to  preoare  a  text  file 
in  an  aooroorlate  form  for  use  by  a  subsequent  process. 
"WORD  STAR",  end  the  "VI"  and  "EDIT"  systems  for  UNIX  were 
analyzed.  These  systems  are  described  m  Aeoendlces  (A), 
CB),  and  (C). 

The  text  editor  can  be  divided  Into  five  major 
functional  categories  of  commands  which  are  supported; 
<Create>,  <Insert>,  <Nodi<y>,  <Delete>,  <Move>,  and 
<Retrleve>, 

1.  Creation 

A  facility  used  to  define  an  empty  file  Into  which 
the  text  will  be  entered.  This  Involves  a  directory  entry 
of  some  type,  the  alloeetlon  of  storaqe  space,  and  the 
creation  of  a  buffer  area. 

2.  Insertion 

Oone  an  objeet  at  a  time  In  relation  to  some 
referenced  point  in  the  text  file*  such  as  the  eursor 
position.  It  Is  possible  to  Insert  any  object  at  a 
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specified  point.  Insertion  it  non-destructive  in  that  tho 
object  is  lntortod  between  existing  contents.  without 
overwriting,  The  object  to  be  Inserted  may  be  entered  by 
the  user,  cone  from  a  buffer,  or  eome  from  another  file. 

3.  modification 

In  relation  to  some  referenced  point  In  the  text 
file  the  current  contents  are  altered  .  Modification  Is 
destructive  In  that  the  current  contents  are  destroyed  by 
writing  over  them.  Global  modification  is  possible. 

4.  Deletion 

In  relation  to  some  referenced  point  In  the  text 
file  an  object  of  any  granularity  level  Is  removed.  Global 
deletion  Is  possible. 

5.  Movement 

The  current  oolnt  of  reference  in  the  text  file  Is 
changed  to  meet  the  desires  of  the  user.  Control  of 
movement  is  possible  at  any  object  level.  The  user  should 
have  the  capability  to  move  to  a  oredeflnad  location  or  to  a 
location  that  meets  some  condition. 

6.  Retrieval 

while  not  dlreetly  responsive  to  user  retrieval 
commands,  the  text  editor  supports  the  user  by  displaying 
the  local  area  around  the  point  of  reference,  in  a  general 
sense  this  Is  a  desired  retrieval  of  text  from  the  tile. 
Retrieval  Is  automatically  done  for  the  user  whan  the  point 
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of  roforonet  changes  to  onsuro  tho  user  eon  establish  tho 
eontoxt  of  tho  point  of  reference, 

8,  PORI)  PROCESSOR 

Pilot  prooorod  by  a  text  editor  eon  bo  proeottod  by  a 
word  Proeossor  twp),  "WORD  STAR",  an  on-line  wp,  and  "WROFP 
•RE",  a  vp  for  tho  OMix  oooratlno  system*,  wore  analyzed. 
Those  two  systems  are  described  in  Appendices  (A)  and  (*>), 
Currently  there  are  two  approaches  to  word  orocesslnas 

(1)  Off-Line  Formatting.  In  addition  to  the  actual 
text  In  the  edited  file,  a  combination  of  special 
characters,  and  characters  strlnqs,  can  be  embedded  In  the 
text  file  for  use  by  the  wp.  These  special  embedded 
character  strings  are  commands  used  by  the  word  processor  to 
produce  the  desired  printed  format  of  the  text  file.  This 
requires  a  two  step  procedure  by  the  user.  The  user  first 
visualizes  the  desired  format  of  the  output  and  then 
translates  It  into  a  combination  of  the  actual  text  and  the 
embedded  WP  commands.  The  text  file  is  then  processed  by 
the  wp.  This  Is  a  level  of  Indirection  that  delays  feedback 
to  the  user  as  to  the  effect  of  a  command, 

(2)  On-Line  Formatting,  In  this  ease,  while  most 
of  the  wp  commands  are  still  embedded  In  the  text  file,  they 
are  Immediately  executed.  As  the  user  Inputs  the  text.  It  Is 
displayed  on  the  sereen  In  the  desired  format.  The  user 
thereby  receives  Immediate  fpedbaex  as  to  the  effect  of 
formattlno  commands.  However,  the  problem  of  the  display 
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format  being  bigger  than  the  display  dimensions  It  a 
problem,  if  only  a  minor  ona. 

Tha  am,  unlike  the  other  application  packages,  does  not 
dlraetly  manipulate  a  data  objeet  in  tha  eoursa  of  its 
operation,  instead,  it  intercepts  a  stream  of  data  from  the 
data  object  and  alters  the  display  format  prior  to  output* 
For  this  reason  is  seems  logical  to  consider  the  wm  to  be  a 
oart  of  the  editor  -  the  application  Package  that 
manipulates  the  data  objeet  upon  which  the  up  depends, 

C.  DATABASE  MANAGEMENT  SYSTEM 

Data  Is  simply  symbols  which  are  stored.  In  and  of 
Itself,  a  datum  has  no  significance,  However,  when  coupled 
to  an  entity,  the  class  of  a  datum  becomes  an  attribute  of 
the  entity  and  the  value  of  the  datum  can  be  used  as 
information  to  describe  an  Instance  of  the  entity.  when 
data  is  stored  in  a  computer  it  is  known  as  a  database.  To 
transform  the  raw  data  into  an  abstraction  suitable  for  a 
person  to  use  and/or  modify  is  the  major  function  of  a 
Database  management  System  (DBMS),  Xn  a  sense  a  DBMS  acts 
as  an  interpreter  between  the  user  and  the  computer*  It 
interprets  user  statements  describing  whet  is  to  be  done 
with  the  database  into  the  lower  level  algorithms  necessary 
to  perform  tne  operation  on  the  eoneeptuai  and  eventually 
the  physical  representation  of  the  data  in  the  computer, 
from  the  perspective  of  the  computer,  the  DBMS  translates 
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the  physical  implementation  of  tha  data  through  tha 
conceptual  raprasantatlon  to  tha  appropriate  uaar  view.  In 
this  way  tha  DBMS  provides  two  levels  of  data  Independence. 
Oata  Independence  implies  that  modification  ean  be  made  to 
the  Implementation  of  tha  data  without  affecting  the  logie 
of  the  epeileatlon  proqrams.  Oata  Independence  between  the 
conceptual  schema  and  its  physical  implementation  allows 
chances  to  the  ohyslcal  Implementation  of  the  conceptual 
schema  while  permlttlna  application  proqrams  to  run  as  it  no 
change  had  occurred.  Similarly,  data  independence  between 
the  conceptual  schema  and  a  user  view  allows  changes  to  be 
made  to  the  conceptual  schema  while  permitting  application 
eroorams  to  run  as  if  no  ehange  had  oeeurred. 

Xn  addition  to  the  data  management  function,  a  DBMS  also 
provides  functions  to  ensure  system  integrity.  Towards  this 
end  a  hams  enforces  database  security  constraints.  The 
security  facility  ensures  that  unauthorized  aeeess  to  data 
Is  not  allowed,  a  DBms  typically  ensures  that  the  reoulred 
properties  of  data  are  guaranteed.  These  properties  ean  be 
either  syntactic,  that  is  structural,  or  semantic,  for 
instance  contained  within  a  specified  domain.  A  DBms 
typically  provides  a  mechanism  to  protect  the  database  from 
a  system  crash  by  regularly  making  baek-up  copies  of  the 
database,  tn  the  event  of  a  system  crash,  a  DBMS  typically 
provides  a  facility  to  restore  the  database  to  a  previously 
consistent  state.  Finally,  In  a  multi-user  environment,  a 
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DBMS  typleally  provides  a  synchronization  aaehanlsa  to 
protect  the  databese  iron  Inconsistencies  whieh  might  result 
from  simultaneous  aecess  to  a  database*  especially  if  one 
access  entails  a  chance  to  a  shared  data  item. 

"DBASE  IX”  and  "SEQUITUP"  were  reviewed  as 
representative  relational  data  base  models  and  are  described 
in  Appendices  (E)  and  (F),  A  relational  DBFS  was  selected 
as  an  IASS  conceptual  database  model  due  to  its  familiar  and 
universally  understood  data  object*  the  relational  table. 
The  basic  organizational  unit  in  the  relational  table  is  the 
named  and  domalned  field,  a  reeord  of  arlty  "n"  In  the 
relational  table  contains  n  fields*  each  containing  a  value 
from  its  domain.  A  relational  table  Is  the  next  higher 
level  of  organizational  abstraction.  The  overall  schema  of 
the  relational  table  Is  defined  bv  physical  properties  of 
the  fields  and  embodies  the  relationship  which  is  defined  by 
the  field  set. 

A  DBms  can  be  logically  divided  into  three  functional 
parts  -  data  definition*  data  manipulation*  and  guery 
retrieval.  These  parts  ean  be  further  refined  Into  tne 
functional  operators  <Create>*  <Xnsert>*  <Modify>*  <Deiete>, 
<hove>,  and  <eetrleve>. 

i.  snnv?" 

The  ezistenee  of  a  relational  table  is  typically  due 
to  a  need  perceived  by  the  user  to  organize  data.  Creation 
is  therefore  the  process  by  which  the  relational  table  is 
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defined  In  e  detebeae  by  lta  identity  end  composition.  The 
existence  of  the  table  la  noted  in  aoee  fore  of  a  detebeae 
table  directory.  The  eoapoeltlon  of  the  table  defined  the 
acheea  of  the  relational  table.  Modification  of  a  uaer 
defined  table  can  be  viewed  as  a  special  ease  of  creation  or 
re*creation.  A  table  name  can  either  be  changed  or  the 
seheaa  redefined.  In  addition  to  these  explicit  methods  of 
ereatlno  relational  tables.  Implicit  methods  also  exist.  As 
a  result  of  the  relational  operation  JOIN,  a  new  relational 
table  ean  be  created.  The  method  of  namlno  the  new 
relational  table  Is  implementation  speeifie.  The  composition 
of  the  table,  however,  is  derived  from  the  schema  of  the 
operand  relational  tables. 

2.  Insertion 

Insert  is  a  component  of  the  set  of  date 
manipulation  operators.  The  action  of  an  insert  is  to  place 
e  record  into  the  relational  table.  The  orioln  of  the  record 
to  be  inserted  Is  irrelevant  to  the  operation.  The  effect  of 
the  operation  is  that  a  new  relational  table  is  derived  from 
the  old  relational  table,  order  not  belno  sloniflcant. 

).  Modification 

Modify  is  a  component  of  the  set  of  data 
manipulation  operators.  The  aetlon  of  a  modify  Is  to  chanme 
the  data  in  a  field,  oaxt's  typically  do  net  restrict  the 
orleln  of  the  new  data  to  what  the  user  supplies  at  a 
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terminal  bat  can  be  as  a  ratal t  of  evaluation  of  expressions 
or  derived  frob  otbor  relations  In  tha  databata. 

4.  Oblation 

Dalata  It  a  component  of  tha  tat  of  data 
Manipulation  operator t  and  It  In  feet  tha  lnvarta  operation 
of  Intart.  Tha  action  of  dalata  it  to  remove  a  record  from 
the  relational  table,  the  final  disposition  of  the  deleted 
record  is  immaterial  to  the  operation.  A  delete  operation  is 
typically  a  two  step  process.  A  record  is  first  morieed  for 
deletion  and  then  explicitly  removed  from  the  table. 

5.  Movement 

The  movement  operator  ean  be  viewed  either  as  a 
passive  data  manipulation  operator  or  a  query  retrieval 
operator.  Movement  encompasses  the  process  of  cnanqlnq  the 
current  point  of  reference  in  the  database.  The  ultimate 
destination  is  determined  from  manlpulatlnq  data  in  the 
database  or  at  a  direct  result  of  a  query  on  the  database. 
The  point  of  reference  can  be  of  any  organizational 
abstraction  from  an  entire  relation  to  an  individual 
character  in  a  field.  This  ranqe  in  movement  implies  that 
this  operator  subsumes  the  theoretical  relational  aiqobra 
operators  PROJECTION  and  SELECTION.  Movement  it  a  required 
operator  in  order  to  teen  and  extract  information  from,  or 
in  conjunction  with*  the  performance  of  any  of  tha  othar 
operations  an  tha  database. 
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6.  Retrieval 

Retrieve  la  exclusively  e  query  response  operator. 
The  condition  of  a  query  specifies  the  information  to  be 
extracted  or  derived  from  a  database*  A  query  ean  be  in 
•any  forms.  Traditionally  a  query  facility  is  embodied  in  a 
specialized  lanauaqe  which  the  user  employs  to  extract 
information  from  the  database.  In  this  simplest  form,  a 
query  is  eaulvalent  to  the  relational  alqebra  PROJECTION 
operator  possibly  following  the  SELECTION  operation  on  the 
referenced  relation.  Queries  can  exist  in  subtler  forms. 
Movement  through  a  database  ean  actually  be  the  result  of  an 
underlylno,  implicit  retrieve  operation.  Some  uses  of  forms 
embody  a  retrieval  operation  as  they  extract  information 
from  a  database  to  derive  Its  contents.  Reports  also  embody 
the  retrieve  operator  in  the  same  way  as  a  form.  Prom  the 
database,  information  is  retrieved  and  displayed  in  a  user 
specified  format. 

D,  ELECTRONIC  SPREAD-SHEET 

An  Electronic  Spread-Sheet  package  provides  an  important 
numerical  modeling  capability  to  the  user.  This  application 
provides  the  user  with  a  place  of  "electronic"  scratehpaper 
for  doing  fairly  complicated  numerical  problems,  and  models 
that  are  of  a  recurring  nature.  Instead  of  reaching  for 
pencil,  paper,  and  calculator  each  time,  the  user  will  call 
the  electronic  spread  sheet  and  by  entering  the  needed 
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values  cause  the  spread-sheet  to  complete  the 
eeleuiatlon/aodel.  It  compliments  the  Inclusion  of  the  word 
processor  and  database  manaoement  system  in  the  IASS.  The 
commercially  available  "VISICALC"  system  was  reviewed,  and 
is  described  in  Appendix  (6), 

Spread-sheets  are  commonly  divided  into  addressable 
(re*, column)  entry  positions,  similar  to  a  checkerboard,  and 
are  used  to  graphically  dlsolay  numerical  data  In  a  tabular 
format.  A  small  portion  of  the  spread-sheet  Is  usually 
visible  on  the  screen  at  any  one  time  and  the  user  must  use 
window  and  screen  commands  to  move  across  the  entire  sheet. 
Each  entry  position  Is  an  Independent  entity  and  can  contain 
any  of  the  data  types  -  character,  numeric,  or  function. 
The  contents  of  an  entry  position  can  be  expressed  In 
relation  to  the  value  of  a  previous  entry  position. 

system  operations  consist  of  <Create>,  <Insert>, 
<Modlfy>,  <*ove>,  <Oelete>,  and  <Retrleve>. 

*•  greats 

The  user  Initializes  a  data  storage  structure  for  a 
new  spread-sheet.  The  dimensions  for  the  new  spread-sheet 
ere  initialized  and  all  entry  positions  are  set  to  null 
values. 

2.  InUSllSSL 

given  an  already  existing  spread-sheet,  the  user 
adds  a  new  column  or  row  to  the  soread-sheet  at  an  indicated 
location,  mis  enlarges  one  of  the  spread-sheet  dimensions 
by  one. 
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3.  Modification 

Change  the  current  value  in  an  existing  entry 
position  to  a  nee  value  or  function. 

4.  Deletion 

Given  an  already  exlstina  spread-sheet,  the  user 
deletes  an  entire  eolumn  or  row  from  the  spread-sheet  at  an 
indicated  location.  This  will  reduce  one  of  the  spread¬ 
sheet  dimensions  by  one. 

5.  wovement 

Allows  the  user  to  view  the  contents  of  the  entire 
soread-sneet  through  the  limited  dimensions  of  the  screen 
display  by  permitting  the  user  to  maneuver  the  screen  across 
the  soread-sneet. 

6.  Retrieval 

The  tabular  display  of  the  spread-sheet  on  the 
user's  seraan  is  the  result  of  a  predefined  retrieval  from 
the  stored  representation.  As  changes  are  made  to  entry 
positions  and  they,  in  turn,  effect  other  entry  positions, 
the  tabular  dismay  is  kept  updated  by  automatic  retrievals. 
Additionally  as  the  user  moves,  or  alters,  the  window  into 
the  spread  sheet  new  information  must  be  retrieved  to  meet 
the  changed  reguest.  The  user  cannot  specifically  as*  for 
information  from  the  system,  but  instead  accepts  the  single 
retrieval  the  screed-sheet  paekage  was  designed  to 
automatically  produce. 
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C.  PORNS  GENERATOR 


By  definition*  •  "fora”  it  a  printed  doeuaent  with 
blanket  to  be  filled  In*  end  "foraet"  It  the  arrangement,  or 
plen*  of  a  presentation.  Traditionally,  a  doeuaent  It 
attuaed  to  be  a  piece  of  paper,  and  the  input  device  used  to 
place  values  onto  the  doeuaent  it  the  huaen. 

In  the  Electronic  Data  Processing  (EDP)  environment, 
these  notions  are  generalized  to  where  a  doeuaent  can  also 
be  derived  from,  or  stored  into,  a  database  or  data  file. 
Regardless  of  the  semantic  generalizations  Introduced  by 
GOP,  the  looleal  view  of  a  fora,  at  well  at  its  function, 
remain  the  same.  A  form  Is  used  as  a  template  to  display 
Information  and/or  collect  a  set  of  data.  A  form  Is 
distinguishable  from  a  reoort  in  that  a  form  represents  only 
one  instance,  or  a  coalescence,  of  a  set  of  data  elements. 
The  report  contains  the  form  as  a  special  case,  hut  repeats 
it  for  each  Instance  In  the  set  of  data  elements. 

a  Form  Generator  is  a  utility  to  assist  the  user  In 
designing  a  dlsplayabie  form  at  "design-time”  and  employing 
it  at  "use-time*.  Since  ereatlon  and  use  times  are 
different*  the  design-time  display  must  represent  the  use- 
time  display  of  the  form  es  closely  as  possible.  Prom  the 
design  the  Per*  Generator  must  translate  the  visual 
specifications  into  the  appropriate  representation  for  use 
by  the  display  function  at  use-time.  In  addition  to  the 
physical  layout  of  the  displayed  form*  the  design  and 
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internal  representation  must  contain  information  regarding 
the  value  association  or  derivation  at  use-tine.  The  DBASE 
II  form  generation  facility,  and  the  separate  "ZIP"  screen 
oriented  form  generator  were  evaluated  and  are  discussed  in 
Appendix  (H), 

The  design-time  environment  Includes  both  Initial  fern 
design  and  design  modification.  Form  design  Is  done  by  use 
of  an  editor  and  an  on-screen  capability  is  essential  to 
achieve  deslqn-tlme  and  use-time  visual  proximity.  The 
editor  eould  be  an  integral  part  of  the  form  generator  or 
separate.  Value  association  is  not  done  by  the  form 
generator  directly.  The  user  states  the  value  association 
of  a  "block"  in  terms  of  the  use-time  function  which  must 
evaluate  the  "block"  values. 

The  orocess  of  form  generation  entails  describinq  both 
tha  display  features  of  a  "blade"  in  the  form  and  the  use- 
time  association.  The  functionel  list  of  operators  to 
sueport  a  form  generator  are  <Create>,  <insert>,  <«odlfy>, 
<helete>,  <Move>,  end  <Retrleve>. 

l.  Creation 

Creating  a  new  form  entails  naming  tha  form  and 
making  It  known  to  tha  raat  of  the  system  for  use.  Only  the 
empty  structure  is  creatad  and  will  rtquire  tha  usar  to 
entar  information  into  It, 


2.  Insertion 


The  user  adds  a  new  "block"  to  the  form  by 
specifying  Its  characteristics.  Characteristics  may  be  - 
position,  prompt*  lnput/output*  type*  and  processing 
information.  A  grouping  of  these  "bloeks"  will  make  a  form. 
Actual  "bloek"  specification  and  addition  is  done  through  a 
level  of  indirection  where  the  user  draws  the  "bloekfsl"  on 
the  sereen  and  the  system  determines  the  earameters 
neeessary  to  make  the  form, 

3.  modification 

The  user  changes  one  or  more  of  the  characteristics 
of  an  already  existing  "bloek". 

4.  Deletion 

The  user  removes  an  entire  "block"  from  the  form. 

5.  Movement 

The  user  has  a  point  of  reference  within  the  olven 
form.  At  any  given  time  some  "block"  Is  the  oolnt  of 
reference*  and  commands  are  available  for  the  user  to  move 
this  oolnt  of  reference, 

6.  Retrieval 

The  user  desires  to  see  the  format  in  which  the  form 
will  be  displayed  both  at  design-time  and  run-time.  The 
retrieval  operation  is  automatic  and  translates  the 
information  stored  In  the  form's  structure  into  the 
appropriate  display.  Actual  desion  and  modification  of  a 
form  Is  done  on  this  display  and  the  form  generator 


determines  the  additional  Information  it  will  naad  to 
recreate  tna  flnlshad  form  on  damand. 

r.  ELECTRONIC  NAIL 

Electronic  Nall  is  a  facility  for  sanding  messages  from 
one  user  to  another*  The  "NAIL"  system  used  by  the  Unix 
operating  system  was  reviewed  and  a  description  Is  given  in 
Aocendlx  (I). 

An  Electronic  Nail  system  uses  a  oredeflned  message  form 
which  contains  Information,  sueh  as  destination,  subject, 
and  main  body.  Once  created,  the  message  Is  sent  to  the 
destination  where  it  is  plaeed  in  a  message  file,  called  a 
"mailbox",  for  reading.  The  major  functional  operations  In 
a  mall  system  are  <Create>,  <lnsert>,  <wodlfy>,  <Delete>, 
<Movement>,  and  <Retrleval>, 

1.  Creation 

The  system  generates  an  empty  message  form  which  the 
user  fills  in, 

2.  Insertion 

Messages  are  Inserted  into  the  various  mailboxes 
that  the  mall  system  maintains.  A  message  is  sent  to 
another  user  by  storing  it  In  the  system  mailbox. 

3.  Modification 

Messages  are  initially  created  with  no  values  in  the 
message  form.  Composing  a  message  therefore,  entails  maxing 
mod if lcatlons  to  the  null  carts  of  the  message. 
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Modification*  can  also  b*  mad*  to  a  massaqa  any  tima  during 


composition,  before  sending  it  to  Its  destination.  Finally, 
fields  in  a  message  may  be  modified  by  the  recipient,  in 
order  to  retransmit  the  message. 

4.  Deletion 

BV  reviewing  messages  from  the  system  mailbox,  they 
are  deleted  from  the  system  mailbox  and  placed  Into  a  loeal 
area.  The  user  may  delete  messaaes  from  the  system  or  local 
mailboxes  at  any  time. 

5.  Movement 

411  the  previous  commands  are  performed  in  relation 
to  a  point  of  reference.  The  point  of  reference  in  a 
mailbox  can  be  changed  by  the  user  in  order  to  browse 
through  the  messages,  or  edit  them, 

6.  Retrieval 

Reading  a  message  Is  done  by  retrieving  the  contents 
of  the  message  fields  and  displaying  them  to  the  user. 

In  review.  Chapter  2  has  shown  that  a  general 
commonality  exists  between  the  functions  of  the  given 
applications.  This  commonality  has  been  presented  as  the  set 
of  six  command  categories  -  <Create>,  <Insert>,  <Modlfy>, 
<D*i*te>,  <move>,  and  <Retrl*ve>,  The  following  chapters 
will  lead  to  an  Integration  based  on  this  commonality. 
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III.  THE  COMMON  DATA  OBJECT 


The  kty  to  achieving  an  integrated  system  which  can 
support  formatted  and  unformatted  data  Is  to  map  the  loolcal 
file  types  associated  with  the  applications,  Into  one 
conceptual  data  object.  This  conceptual  data  object  Is  then 
part  of  a  model  of  the  applications  and  their  use.  The 
functional  Intersection  of  operations  on  the  files  can  be 
implemented  by  a  sinale  set  of  primitive  conceptual 

operations  on  the  common  data  object. 

! 

The  TASS  must  represent  eaeh  of  the  logical  file  types 

i 

associated  with  the  I  Included  applications  in  such  a  way  as 

I 

to  support  the  essential  functions  of  each  application.  The 

i 

data  object  chosen  jjor  this  IASS  dealer  Is  the  table.  The 

i 

table  is  a  natural  method  of  eroanlzlno  data  and  therefore 

I 

should  be  understandable,  even  by  naive  users.  A  table  is  a 

i 

two  dimensional  array  contalnlna  rows  and  columns.  The  IASS 
usee  the  table  to  represent  e  "reel-world"  entity.  Each 
column  represents  on*  attribute  of  that  entity  and  eaeh  row 
represents  a  unique  occurrence  of  an  entity.  A  table  is 
almost  equivalent  to  a  relational  database  relation,  except 
that  a  table  implies  that  rows  and  columns  have  an  order  In 
the  table  which  ean  be  used  In  e  positional  addrasslnq 

i 

scheme.  Since  addrasslnq  is  associative  In  e  relation,  the 
table  matt  include  Columns  which  represent  Key  values  to 
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uniquely  Identify  eech  row.  with  this  slight  nod if lcatlon, 
eny  detue  in  e  table  can  be  eeeessed  by  specifying  the  name 
of  the  teble.  the  velue  of  the  key.  end  the  neme  of  the 
ettribute  containing  the  datum.  Hereafter,  the  eommon  data 
object  will  be  referred  to  as  a  relational  table.  Rows  of 
such  tables  are  usually  referred  to  as  "tuples"  and  columns 
are  referred  to  as  "attributes".  The  assumptions  to  be  made 
coneernino  the  relational  table  in  this  thesis  are:  (l)  Row 
or  column  order  is  not  significant.  (2)  All  columns  are 
named  and  must  be  unique  within  the  table,  and  (3)  Each  row 
Is  uniquely  identifiable  by  a  key  value. 

In  the  following  sections  eaeh  logical  file  type  will  be 
described  as  a  relational  table.  The  attributes  of  each 
table  tvoe  were  selected  based  uoen  its  perceived  primary 
use.  As  such,  the  set  of  attributes  associated  with  each 
table  was  determined  in  order  to  provide  the  information 
necessary  to  support  that  primary  application.  These  tables 
are  merely  special  cases  of  a  relational  database  table, 
eased  on  their  predefinition,  their  use  can  be  bounded 
within  the  primary  application  and  therefore  een  be  "typed”. 
To  be  of  a  certain  type,  it  is  sufficient  that  the  table 
contains  the  minimum  set  of  attributes  necessary  for  that 
specific  type  as  e  subset  of  its  total  set  of  attributes, 
(e.o.  A  given  system  table  mloht  have  five  attributes.  Three 
of  those  are  the  required  attributes  for  a  type-1 
amplication  table.  The  remaining  two  attributes  eould  be  tne 
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requir'd  attribute*  for  a  type-2  table.)  This  Implies  that. 
«•  an  implementation  Issue*  a  slnole  table  eould  be 
considered  to  nave  multiple  types*  but  for  simplicity  let  us 
assume  that  a  table  will  nave  only  one  type.  As 
applications  are  added  to  tne  XA3S *  the  aceomoenylno  minimal 
set  of  attributes  must  be  defined  to  represent  tne  new  table 
tvoe.  There  are  many  structural  orqanizatlons  which  eould 
reoresent  a  loqleal  file  tvoe.  The  final  decision  on  the 
oraanlzatlon  of  the  table  must  be  made  to  maximize  the  use 
of  the  conceptual  level  operations  that  ere  available  to 
manipulate  the  data  In  the  table.  These  conceptual  level 
operations  win  be  covered  In  Chapter  4.  It  is  important  to 
note  that  the  table  Is  a  structural  oraanlzatlon  used  as  a 
model  and  therefore  problems  may  arise  In  expresslna  the 
actual  applications  by  the  table  model. 

A.  TEXT 

Text*  as  data  in  a  text  file*  is  a  "continuous"  string 
of  Individual  characters  from  some  character  set  (e.g. 
ASCII).  The  use  of  text  as  data  is  by  character*  where  each 
character  Is  a  unit  of  data  used  in  an  application. 

Objects  such  as  words*  sentences*  lines*  or  paragraphs 
ere  looleal  abstractions*  hidden  in  the  text*  that  are 
useful  as  information  only  to  a  human  user.  Any  IAS S 
manipulation  that  may  alter  this  hidden  logical  abstraction 
will  dlreetly  effeet  the  ability  of  the  IASS  to  transform 
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the  data  back  into  lnfornatlon.  Ce.g.  deleting  avary  othar 
word. 3  This  will  require  the  imposition  of  limitations  on 
the  ota  of  tabla  ooaratort  on  tha  text  tabla  in  ordar  to 
protact  this  logical  abstraction,  (i.a,  operation*  incapable 
of  talcing  into  account  tha  logleal  abstraction  of  taxt  alii 
not  ba  used.) 

Tha  only  naturally  oeeurrlng  data  elements  In  a  taxt 
file  is  tha  single  character,  and  tha  entire  character 
stream.  Their  domain  is  all  the  elements  in  the  applicable 
character  sat.  These  two  problems,  the  continuous  nature  of 
text  and  its  discreteness  being  limited  to  a  single 
character  or  the  entire  file,  make  the  text  file  the  most 
difficult  file  type  to  model  as  a  relational  table.  The 
table  must  guantize  the  continuous  text  stream  Into  column 
units,  thus  destrnyina  the  continuity  of  the  text. 
Additionally,  while  the  relational  tabla  operators  recognize 
the  column  as  being  an  object,  in  fact  it  has  no  natural 
occurrence  in  the  text  file.  Any  definition  of  a  column 
which  represents  text  objects  between  the  single  character 
and  the  entire  text  file,  is  an  arbitrary  guantlzatlon  of 
the  text  streasi.  Figure  3,1  illustrates  the  problem  by 
arbitrarily  choosing  a  column  size  eouel  to  ten  characters 
(the  character  represents  a  carriage  return  and  line 
food).  This  division  of  the  text  stream  into  units,  for  use 
as  tuples  in  a  table,  has  no  corresponding  unit  in  the 


original  text  file,  and  has  Imposed  structural  llaitatlons 
by  the  eolumn  boundaries , 

(a)  Text  Stream 
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(b)  Tuole  Representation 


Figure  3.1  •  Text  Representation  Problem 

This  problem  of  using  a  "discrete"  reoresentatlon  will 
have  to  be  acknowledged  and  steps  taken  at  the  apollcatlon 
level  to  ensure  the  limitations  Imposed  by  the  problem  are 
not  violated.  In  determining  the  size  of  a  text  tuple, 
neither  the  single  character  nor  the  entire  file  are 
acceptable  units  to  be  used  in  the  relational  table  model 
since  they  would  require  a  large  amount  of  processing  by  the 
application  level  to  transform  them  into  usable  units.  (The 
argument  is  similar  to  memory  management  questions  of  oaglng 
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versus  segmentation  and  how  loro*  each  unit  should  bo.)  Sent 
arbitrary  sis#,  between  the  two  extremes,  will  have  to  be 
chosen  during  Implementation.  For  now  it  is  assumed  that  the 


six#  limit  exists. 

The  text  file  can  be  conceptually  viewed  as  a  text 
table,  as  in  Figure  3.2.  The  text  stream  is  represented  by 
the  set  of  rows  in  the  table.  Eaeh  "contents"  column  is 
densely  packed  in  that  no  unused  space  is  left  in  any  row, 
except  the  very  last  row  in  the  table.  The  text  table  does 
not  meteh  in  any  way  the  oereelved  "display"  of  the  text 
file,  as  shown  in  Figure  3.1,  The  display  structure  (line- 
oriented,  screen-oriented,  or  whatever)  Is  considered  an 
application  level  issue  and  will  be  coveted  there.  Each  row 
in  the  text  table  has  a  unique  sequence  number,  "Id",  to 
mark  the  relative  position  of  its  contents  in  the  text 
stream. 


Id  contents 


line-1 

llne-2 


llne-n 


Figure  3.2  -  Text  Table 
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B.  DATABASE 


A  relation  In  a  relational  database  is  described  as  a 
table,  as  shown  in  Figure  3.3.  Relational  database  tuples 
are  represented  as  the  rows  of  a  table  and  the  attributes  as 
the  columns.  The  description  of  an  attribute  is  defined  by 
the  user,  and  the  set  of  attributes  define  the  modifiable 
structure  of  the  relation  table.  Chapter  1,  Section  (C) 
covers  the  concepts  behind  the  relational  DBMS  in  oreater 
detail. 


id  atr-i  atr-2 

atr-n 

tuple-l 

1  i  1  m 

1 

tuoie-2 

"lF| 

1 

• 

1  1  f 

• 

r| " 

tupie-n 

"i 1 "  V  1  i 1 

1  1  1  • 

i  i 

Figure  3.3  •  Relation  Table 


C.  SPREAD-SHEET 

A  spread-sheet  Is  a  database  used  as  a  numerical  model 
in  a  predefined  tabular  display  format,  a  spread-sheet  can 
be  represented  as  a  collection  of  entry  position  tuples  in  a 
table,  as  shewn  In  Figure  3.4.  Caeh  row  in  the  table 
represents  e  single  entry  position  In  the  spread-sheet.  The 
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table  eoluans  raeraaent  tha  pradatarainad  alamanta  naeaaaary 


to  daaerlba  tha  antry  position,  such  as  tha  location,  valua, 
and  function. 


Id  location  valua  function 


Bosltlon-1 

1 

1 

*  ms 

1 

oosltlon-2 

!  IT  1  T,  " 

"  1 

l 

i 

» 

• 

1 

l 

i 

ms 

oosltion-n 

T  1 

1 

1  as 

!  1 

Flqura  3.4  -  Spraad  Shaet  Table 


D.  FORK 

A  form  Is  a  template  throuoh  which  Input  and  output 
values  are  transmitted,  Tha  Information  stored  in  a  form 
database  Is  used  to  preoare  the  visual  image  of  tha  template 
in  a  user  specified  format, 

Tha  basic  subunit  of  the  form  la  called  a  "block",  and 
It  represents  a  basic  unit  of  data  for  the  form,  Tha  easiest 
way  to  visualise  a  "block"  Is  to  consider  tha  internal 
Revenue  Service  1040  Tex  Form,  It  is  used  as  an  Input  form, 
and  each  entry  has  a  eorrespondlno  number  to  identify  it  as 
a  separate  entity,  or  "block".  Each  of  these  "bloeks"  has 
an  a  position  on  the  form,  an  Identifying  number,  a  prompt, 
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•nd  space  for  an  entry  of  some  type.  This  neons  that  the 
forn  table  oust  Include  positional  data  for  the  bloc*  as 
•ell  as  data  to  determine  how  the  bloeie  Is  to  be  used  for 
speelfle  applications. 

A  forn  ean  be  represented  as  a  collection  of  tuples 
contained  In  a  table,  es  shown  In  Figure  3.5,  Each  row  In 
the  table  represents  a  single  "bloc*"  on  the  form  and 
contains  a  description  of  the  "bloeie".  The  columns  of  the 
table  are  the  predefined  attributes  of  a  bloeie  -  unlaue  id, 
screen  location,  prompt  string.  Input  or  outout  identifier, 
and  the  functional  use  of  the  bloeie.  Each  table  column 
represents  an  element  of  that  description. 


id  location  prompt 


i/o  function 


block-1 

l 

1 

1 

bloek-2 

i 

™  1  "H" 

1 

i 

-  T,“(-' . 

1 

as 

bloek-n 

i 

1 

i 

figure  3,5  -  form  Table 


The  "id"  Is  a  unloue  Identifier  tor  the  bloeie  and  would 
be  system  controlled,  "Location"  specifies  the  sterting 
position  for  the  "block"  on  the  fore.  If  reoulred,  e 
•prompt"  string  could  be  Included  to  indicate  the  purpose  of 


the  entry  position  on  the  torn  (e.g,  Nano#  Address,  Number 
of  exemptions,  etc,).  The  "i/o"  field  will  tell  the  Pore 
Generator  how  to  interpret  the  "function11  field.  The  exeet 
use  of  the  "l/o”  field  Is  Implementation  dependent,  but  soae 
obvious  entries  ere  "Input",  "output",  end  "text".  Lestly, 
the  "function*  field  will  contain  a  command  string  for  the 
bloek.  Xf  It  is  an  input  block,  then  the  "function”  field 
might  eontaln  the  location  where  the  user  entered  value  is 
to  be  stored.  Xf  It  Is  an  output  block.  It  might  eontaln  a 
query  to  be  made  on  a  database.  Xf  It  is  a  text  bloek.  It 
might  eontaln  the  name  of  the  text  file  that  Is  to  be 
Inserted  In  the  form.  As  can  be  clearly  seen,  the  actual 
use  of  the  form  table  will  be  very  Implementation  dependent 
and  such  issues  win  not  be  directly  addressed  In  this 
thesis. 

E,  ELECTRONIC  NAIL 

Electronic  Nall  Is  a  preformatted  message  sent  to 
another  user.  Data  contained  in  a  message  can  be  used  as 
Information  to  determine  addressee  and  subject  assocleted 
with  a  message,  the  data  in  a  messaae  is  manipulated 
typically  In  the  eourse  of  an  editing  session  or  by  an 
application  program  to  output  a  message  to  be  read  by  the 
recipient.  A  "mailbox"  can  contain  any  number  of  messages. 
Each  message  contains  a  unique  XO  number,  heading,  and  body. 
The  XO  attribute  Is  a  unloue  identifier  of  a  message  In  a 


mailbox.  The  domain  of  tha  ZD  attribute  1*  all  unlqua 
idanelflars  a*  dafinod  In  tha  xyitaa.  Tha  ZD  eould  ba  loeal 
to  a  mailbox,  or  ba  of  a  global  nature,  Tha  body  of  tha 
maaaaga  la  textual  and  its  domain  it  a  continuous  stream  of 
eharaetars  or  a  rafaranea  to  a  text  file.  Heading  consists 
of  an  originator,  redolent,  data,  and  subject,  Tha 
originator,  recipient,  and  subject  are  character  strings  of 
some  maximum  length.  The  date  is  some  allowable  value  as 
determined  by  the  date  convention  used  bv  the  system.  Each 
message  tuole  is  a  complete  message  being  routed  from  a 
sender  to  a  receiver (s). 


Tha  mall  flla  can  be  represented  as  a  collection  of  mall 
tuples  contained  in  a  table,  as  shown  in  Figure  3.6,  A 
"mailbox"  is  a  table  with  tha  rows  raorasantlng  individual 
messages  and  tha  columns  representing  the  predetermined 
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format  of  the  message,  such  «s  from,  to,  Cats,  subject,  and 
main  body. 

This  will  and  tha  discussion  of  representing  the  logical 
file  types  as  a  single  conceptual  data  object  in  the  form  of 
a  relational  table.  This  chapter  has  shown  that  each  of  the 
five  logical  file  types  can  be  mapped  into  a  table  format 
with  varylnq  dearees  of  success.  A  "secret"  that  wili  be 
possessed  by  the  aoolicatlon  level  is  lust  how  successful 
this  maoolng  was.  Of  the  presently  included  file  types  only 
the  text  type  has  shown  signs  of  major  problems.  However, 
similar  situations  could  occur  as  new  applications  are  added 
to  the  IASS.  The  solution  to  the  problem  Is  to  accomplish  at 
the  application  level  what  cannot  be  done  at  the  conceptual 
level  due  to  the  modeling  limitations.  The  next  chaoter, 
Chapter  4,  win  cover  the  conceptual  ie«el  operations  that 
are  available  to  manipulate  the  common  data  object  tables. 
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IV,  operational  intersection 

A  major  concept  behind  the  Integrated  Application 


Software  system 

is 

the 

existence 

of  a 

eommon 

"conceptual 

level"  that  is 

used 

by 

all 

the 

included 

aopllcatlon 

programs.  It 

Is 

important 

to 

note 

that 

it  is  the 

application  proorams,  and  not  the  user,  that  will  interface 
with  the  conceptual  level. 


"APPLICATION  LEVEL" 


■CONCEPTUAL  LEVEL" 


I  PRIMITIVE  | 
I  OPERATIONS  I 


I  COMMON  | 

I  DATA  I 

I  OBJECT  I 


Figure  *,i  •  IASS  Conceptual  Level, 

This  conceptual  level  will  manage  the  data  in  the  eonaon 
data  object,  described  in  Chapter  3,  A  set  of  primitive,  or 
basle,  operations  designed  to  manipulate  the  eommon  data 
object  and  enforce  Integrity  constraints  will  be  included  at 
this  level,  Figure  4,1  illustrates  the  conceptual  level. 
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The  application  packages  will  eall  these  operations  to 
perform  desired  nanloulatlons  at  the  conceptual  level  In 
support  of  the  user.  The  specific  application  determines 
the  combination  of  primitive  operations  neeessary  to 
retrieve  data  fron  the  data  tables  in  conformance  with  the 
use  of  the  table  as  a  model  of  the  application.  Only  those 
operations  that  cannot  be  accomplished  at  the  conceptual 
level,  due  to  modeling  failures,  need  be  included  in  the 
application  level. 

A,  BASIC  OPERATIONS 

The  set  of  table  primitive  operations  is  the  source  of  a 
major  IASS  operational  Intersection.  All  applications 
attached  to  the  IASS  can  use  these  commands  in  order  to 
perform  their  function.  However,  as  modeling  problems  will 
exist,  each  application  area  may  have  limits  that  make  a 
certain  operation  meaningless, 

Slnee  the  common  data  object  is  a  relational  table,  the 
natural  set  of  primitive  operations  are  the  basic  table 
manipulation  operations  Inherent  from  relational  database 
theory.  The  operations  are  named t  INSERTION,  MODIFICATION, 
DELETION,  PROJECTION,  SELECTION,  UNION,  SET  DIFFERENCE, 
CARTESIAN  PRODUCT,  INTERSECTION,  QUOTIENT,  JOIN,  and  NATURAL 
JOIN,  These  operations  are  set  theoretic  in  that  their 
operands  ara  tables  (sets  of  tuples)  and  their  results  are 


tables.  This  faatura  of  the  relational  operators  eliminates 
the  need  for  any  application  to  be  concerned  with  Iteration 
control.  These  operators  are  divided  into  two  croups.  Unary 
and  Binary,  based  on  the  number  of  operands  reaulred. 
l.  Unary  Table  operations 

The  first  five  operators  are  unary  operators  in  that 
they  use  a  single  table  operand.  The  operators  are: 

a.  Insertion 

Given  a  relation  R,  INSERTION  adds  a  new  tuole 
to  R  at  a  specified,  or  default,  location. 

b.  modification 

Given  a  relation  R,  MODIFICATION  changes  one,  or 
more,  of  the  components  of  a  tuple,  or  tuples,  in  the 
relation  R. 

c.  Deletion 

Given  a  relation  R,  DELETION  removes  a  tuple,  or 
tuples,  from  the  relation  R, 

d.  Rroleetlen 

Given  a  relation  R  of  arlty  "a",  a  PROJECTION  of 
R  Is  a  relation  formed  by  removing  some  of  the  components  of 
R  and/or  rearranging  some  of  the  remaining  components. 

o.  Selection 

Given  a  relation  R,  a  SELECTION  ,n  R  is  the  set 
of  tuples  In  R  that  make  true  some  conditional  statement 
based  on  the  components  of  R.  The  operands  of  the 
conditional  statement  are  constants  or  the  comoonents  of  R. 
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The  operations  of  tha  conditional  stateaent  ara  tha 


arithmetic  eonparison  operators  -  lass  than,  equal  to, 
qraatar  than,  lass  than  or  equal  to,  greater  than  or  equal 
to,  and  not  equal  to  -  and  tha  logical  operators  -  AND,  OR, 
and  NOT. 

2.  Binary  Table  Operators 

The  seven  binary  operators  will  use  two  tables  as 
operands.  A  description  of  the  seven  oeerators  follows  and 
for  help  in  understanding  them,  some  examples  will  be  given. 
For  that  purpose  two  "representative  relations"  are  given  in 
Figure  4.1  for  use  in  each  of  the  descriptions  and  examples. 


A  I  B  1  C 


D  I  E  I  H 


Relation  "R" 


Relation  "S" 


Figure  4.1  -  initial  relational  tables. 


a.  Union 

Given  two  relations,  R  and  5,  the  UNION  of  R  and 
S  are  those  tuples  that  are  in  R,  or  s,  or  both.  The  union 
operation  is  denoted  by  (Ru  8),  and  Figure  4.2  shows  the 
results.  Both  tables  oust  be  of  the  same  arlty,  and  an 
attribute  in  the  first  table  must  be  matched  by  the  same 
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attribute  In  the  second  table,  (i.e.  in  this  ease  0  «  A.  E 
a  B,  and  F  a  C.) 


a 

d 

e 

b 


b 

a 

b 

9 


e 

f 

d 

a 


figure  4.2  -  Result  of  CR  U  S). 


b.  Set  Difference 

Given  two  relations*  R  and  S,  the  SBT  DIFFERENCE 
of  R  and  s  is  the  set  of  tuples  that  are  in  R,  but  not  In  S. 
SET  DIFFERENCE  Is  denoted  (R  -  S),  and  Figure  4.3  shows  the 
results,  Both  tables  must  be  of  the  same  arlty,  and  an 
attribute  in  the  first  table  must  be  matched  by  the  same 
attribute  In  the  seeond  table.  (I.e,  in  this  ease  D  a  k,  E 
a  B,  and  F  a  C.) 


k 

B 

C 

a 

b 

c 

c 

b 

d 

Figure  4.3  -  Result  of  (R  •  S). 
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e.  cartesian  Product 


Given  two  relations,  R  of  erlty  "el”  end  S  of 
arlty  "a2",  the  CARTESIAN  PRODUCT  of  R  end  s  Is  the  set  of 
tuples  of  erlty  "(el  ♦  e2>"  whose  first  el  components  form  e 
tuple  In  R  end  whose  lest  s2  components  form  e  tuple  in  S. 
CARTESIAN  PRODUCT  Is  denoted  by  (R  x  3) ,  end  Figure  4.4 
shows  the  results.  Eaeh  of  the  resulting  ettrlbutes  of  the 
cartesian  product  operstlon  must  be  unique. 


d.  Intersection 

Given  two  relations,  R  and  8,  the  INTERSECTION 
of  R  end  s  la  the  set  of  tuples  that  are  in  both  R  end  3, 
not  those  that  only  oeeur  In  one  relation.  INTERSECTION  is 
a  shorthand  for  R  •  (R  -  3),  is  denoted  by  (R  A  3),  and 
figure  4.3  snows  the  results*  Both  tables  must  be  of  the 
sees  arlty,  and  an  attribute  in  the  first  table  must  be 
matched  by  the  same  attribute  in  the  second  table,  (i.e.  In 
this  ease  0  ■  A,  E  •  B,  and  f  ■  C.) 
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B 


C 


Figure  4,5  -  Result  of  CR  A  S). 


e.  Quotient 

Given  two  relations,  X  of  arity  "al"  and  Y  of 
arlty  "a2"  where  al  Is  areater  than  a2  and  there  Is  at  least 
one  tuple  In  S,  the  QUOTIENT  of  X  and  Y  is  the  relation  of 
arlty  (al  •  a2)  composed  by*  First  take  the  projection  of  X 
over  the  first  (kl-k2)  eomoonents  and  call  the  resultlna 
relation  T»  second,  take  the  CARTESIAN  product  of  T  and  Y 
and  call  the  resultlnq  relation  U.  Lastly,  deternlne  the  SET 
DIFFERENCE  between  U  and  X, 
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Relation  X 
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(X  ♦  Y) 

Figure  4,5  -  Result  of  (If!), 
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QUOTIENT  Is  denoted  by  (X  +  Y),  and  Figure  *,6  gives  sample 
X  and  Y  relations,  and  the  result  of  (X  +  Y) • 

2.  Join 

Given  two  relations,  R  of  arlty  ■al"  and  z  of 
arlty  ”a2",  the  result  of  a  JOIN  would  be  a  relation  of 
arlty  (al  ♦  a2)  containing  those  tuoies  in  the  CARTESIAN 
PRODUCT  of  R  and  Z  where  a  component  In  R  stands  In  some 
relation  to  a  component  In  Z,  A  JOIN  is  denoted  by  R  |X|  Z, 
and  Figure  4.7  shows  a  sample  relation  Z  and  the  results  of 
(R  IXI  Z). 
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b 

Relation  Z  (R  Dfl  Z) 

BaD 

Figure  4.7  -  Result  of  (R  IXI  Z). 

BaD 

g.  Natural  Join 

Given  two  relations,  R  of  arlty  "al"  and  u  of 
arlty  ”a2”  where  R  and  U  have  "cl"  attribute  names  In 
common,  the  result  of  a  NATURAL  JOIN  is  a  relation  of  arlty 
(al  ♦  a?  -  el)  formed  by  talcing  the  CARTESIAN  product  of  R 
and  U,  then  performing  e  SELECTION  based  on  the  equality  of 
the  eomnon  attributes  In  the  tuples,  and  lastly  performing  a 
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PROJECTION  with  all  possible  attributes  listed  once.  NATURAL 
JOIN  is  denoted  by  (RfXIU),  and  Figure  4.8  shows  a  sanoie 
relation  u  and  the  results  of  (RUQU), 
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Relation  U  (R  iXt  U) 

Figure  4,8  -  Results  of  (R1XIU). 


B.  SUITABILITY  OF  OPERATIONS 

Looking  at  the  conceptual  data  object  as  the  relational 
table,  and  given  tne  list  of  operations  from  section  (A), 
above.  It  should  be  obvious  that  any  operation,  or  series  of 
operations,  performed  on  a  table  will  produce  a 
theoretically  useful  relational  table  for  some  application. 
It  will  have  a  valid  table  structure  and  therefore  can  be 
manipulated  by  any  operator.  There  are  an  lnflnlt*  number 
of  manipulation  possibilities  which  ean  result  In  a  endless 
speculation  of  applications.  The  conceptual  view  of  the 
table  and  its  operators  only  takes  on  significance  when 
bounded  by  some  application.  It  Is  the  application  that 
gives  meaning  to  the  usefulness  or  unsuitability  of  some 
operation  or  series  of  operations.  Therefore,  the  intention 
of  this  section  Is  to  measure  the  usefulness  of  the  basle 
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relational  operations  within  the  functional  seope  implied  by 
the  selected  set  of  applications  data  types  described  In 
Chapter  3. 

Before  describing  each  of  the  operations  It  is  Important 
to  define  some  of  the  descriptive  words  that  will  be  used 
for  the  oeerations: 

Table  Structure  -  the  number  of  attributes,  or  fields# 
the  table  contains  and  the  characteristics  of  each  (name# 
type,  sl2e>. 

Syntactically  Correct  -  the  results  of  the  operation  is 
within  the  bounds  of  the  operation  definitions  oresented  in 
Section  (%)  above.  There  are  two  subsets  of  this 
descriptor! 

meaningful  Result  •  The  result  of  the  operation  will 
be  a  table  with  an  Identified  set  of  attributes  and  in  all 
probability,  at  least  one  tuple.  The  resulting  table  will 
have  the  same  structure  as  the  original  table#  or  one  of  the 
original  tables,  and  win  therefore  be  of  that  identifiable 
type.  The  application  will  be  able  to  successfully  use  the 
resulting  table. 

meaningless  Result  -  The  result  of  the  operation 
will  be  a  table  with  an  identified  set  of  attributes  and  in 
all  probability#  at  least  one  tuple.  The  result  will  have 
the  same  structure  as  the  original  table#  or  one  of  the 
original  tables,  and  therefore  will  be  of  that  identifiable 
type.  However#  due  to  modeling  or  inefficiency#  the 
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resulting  table  will  create  difficulties  for  the 
application. 


Syntactically  Zneorrect  -  The  operation  violates  one  or 
aore  of  the  bounds  stated  in  the  definitions  presented  in 
Section  (A)  above. 

Xn  the  next  two  subsections  the  effects  of  the  various 
operations  will  he  discussed.  Subsection  (1)  will  cover  the 
results  when  the  operators  are  used  on  tables  of  the  same 
type.  Subsection  (?)  will  cover  operators  used  on  tables  of 
differing  types. 

1.  Intra-Type  Operations 

This  section  win  cover  the  effects  of  twelve  basic 
relational  operations  when  the  operands  are  the  sane  type  of 
tables  -  text,  database,  soread-sheet ,  form,  or  mail.  This 
section  does  not  caver  the  results  of  mixed  type  operations 
as  they  will  be  covered  in  Subsection  C2),  At  the  conclusion 
of  this  Subsection,  Table  4,1  will  sumnarlze  the  flndlnos. 

The  very  simple  operations  such  as  INSERT,  modify,  and 
OELETE  will  not  be  dlseussed  in  the  context  of  each  table 
type  since  they  are  the  minimum  operations  necessary  to 
manipulate  data  in  any  table  type  and  therefore  meaningful 
for  all  table  types. 

a.  Text  Table  Type  Operations 

The  incompatibility  between  a  text  file  and  its 
representation  as  distinct  units  are  revealed  when 
attempting  to  apply  the  relational  operators  to  the  text 

SO 
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table.  What  la  In  i  tuplt  of  text  la  merely  •  substring  from 
the  original  taxt  stream.  As  such,  tha  situations  where  a 
tuola  ean  stand  alona  as  data  for  operations  other  than  taxt 
processing  are  Halted,  since  the  doaaln  of  the  "contents" 
field  is  all  character  strings  from  the  character  set.  there 
is  no  canonical  ordering  between  the  character  strings. 
Whereas  eouallty  between  contents  fields  ean  be  established, 
there  Is  no  other  comparison  operator  which  will  have 
applicability. 

<1)  Projection 

The  PROJECTION  operation  is  meaningful, 
slnee  it  Is  necessary  to  retrieve  either  the  "contents”  or 
the  "id"  field  from  the  text  table. 

(7)  Selection 

The  SELECTION  operation  Is  meaningful  but 
there  are  restrictions.  Tuples  would  be  selected  from  the 
table  by  performing  the  SELECTION  condition  on  the  "Id” 
field.  The  "contents"  field  presents  difficulties  when  used 
as  a  basis  of  the  SELECTION  condition  since  it  ean  only  be 
eoaoared  for  equality,  and  that  requires  an  exact 
specification  of  the  contents  in  the  condition. 

CD  union 

The  onion  operation  is  meaningful  on  taxt 
files  and  results  in  "appending”  the  second  file  to  the  end 
of  tha  first,  but  there  are  pedaling  problems.  The 
resulting  text  table  could  nave  more  that  one  tuple  with  the 
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same  "id"  f laid.  For  this  reason  the  union  operation  should 
be  considered  with  care. 

\  > 

1 4 )  Sat  Difference  ^ 

the  SET  DIFFERENCE  operation  Is  meaningful, 
but  there  are  modeling  problems.  This  operation  must  be 
used  keeping  In  mind  Its  exactness.  Only  tuples  from  the 
first  table  exactly  matehlno  tuples  In  the  seeond  will  be 
removed.  It  cannot  be  guaranteed  to  remove  duplicate 
strings  from  the  text  file  slnee  the  text  table  model  cannot 
accurately  represent  the  text  file. 

(5)  Cartesian  Product 

The  CARTESIAN  PRODUCT  is  Incorrect  since 
the  resulting  table  structure  will  have  duplicate 
attributes. 

C6)  intersection 

The  INTERSECTION  operation  is  meaningful, 
but  there  are  modeling  problems.  The  result  would  be  the 
removal  of  all  tuples  from  the  first  text  table  that  were 
not  also  In  the  second  text  table.  It  cannot  be  guaranteed 
to  find  the  common  strlng(s)  In  two  text  files  slnee  the 
text  table  model  eannot  accurately  represent  the  text  file, 

(7)  Quotient 

The  QUOTIENT  operation  Is  incorreet  since 
both  text  tables  are  of  the  same  arlty. 
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(8)  Join 

The  JOIN  operation  Is  ineorreet  slnee  the 
resulting  table  would  have  a  structure  with  duplicate 
attributes. 

(9)  Natural  Join 

The  NATURAL  JOIN  operation  is  meaningful. 

•  but  since  it  duplicates  the  effect  of  the  INTERSECTION 
operation  in  a  less  efficient  manner  it  should  be  considered 
meaninaless. 

b.  Spread-Sheet  Table  Type  Operations 
Cl)  Projection 

The  PROJECTION  ooeretlon  is  meaningful  for 
such  operations  as  retrieving  the  information  contained  in  a 
specific  column,  or  columns,  of  the  table, 

(2)  Selection 

The  SELECTION  operation  is  meaningful  for 
removing  a  tuoie,  or  tuples,  from  the  table  for  processing, 

(3)  Union 

The  result  of  the  UNION  operation  on 
spread-sheet  tables  is  meaningful,  but  there  are  modeling 
problems.  The  resulting  table  could  now  have  more  than  one 
tuple  attempting  to  represent  the  same  entry  position, 
tuples  no  longer  representing  the  proper  entry  position, 
and/or  entry  positions  no  longer  relating  to  their  proper 
preceding  entry  positions.  It  is  almost  certain  that  sueh 
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problems  will  oeeur  end  for  that  reason  the  UNION  operator 
should  be  considered  with  care. 

(4)  set  Difference 

The  SET  DIFFERENCE  operation  Is  meaningful, 
but  there  are  modeling  problems.  The  result  of  the 
operation  Is  baslely  those  entry  positions  that  are  unique 
to  the  first  spread  sheet  and  net  to  the  second.  To  ensure 
usability  the  Implementation  must  include  positional  and 
value  information  in  the  tuole.  The  tuele  cannot  depend  on 
order  in  the  table  for  position,  or  functions  relating  to 
other  tuples  for  value,  since  these  other  tuples  may  have 
been  removed  hy  the  3FT  DIFFERENCE  operation. 

(4)  Cartesian  Product 

The  CARTESIAN  PRODUCT  operation  is 
incorrect  since  the  resultina  table  structure  vould  have 
duplicate  attributes. 

(4)  Intersection 

The  INTERSECTION  operation  on  spread-sheet 
tables  Is  meenlnqful,  but  there  are  modeling  problems.  The 
reasons  are  the  same  as  those  given  for  SET  DIFFERENCE 
above. 

(7)  Quotient 

The  QUOTIENT  operation  Is  ineorreet  sinee 
both  spread-sheet  tables  are  of  the  same  arlty. 

(!)  Join 

The  JOIN  operation  Is  incorrect  since  the 
resulting  table  structure  would  have  duplicate  attributes. 
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The  NATURAL  JOIN  operation  1*  meaningful, 
bat  daplleotot  tno  effoet  of  the  INTERSECTION  oporotlon  in  • 
loss  offielont  manner  ond  mould  thorotort  bo  eonoldorod 
meaningless. 

c.  Form  Table  Typo  Operation* 

(1 )  Projection 

The  PROJECTION  operation  is  meaningful, 
slnee  it  can  be  used  tor  retrieving  oarts  of  the  block 
description  used  in  the  application. 

(2)  Selection 

The  SELECTION  operation  is  meaningful, 
slnee  it  ean  be  used  for  retrieving  the  block  descriptions 
used  by  the  aoplleatlon. 

(3)  Union 

The  union  operation  is  meaningful,  but 
thare  are  modeling  oroblem*.  The  resulting  table  could 
contain  tuples  that  are  competing  for  the  sane  position  on 
the  display.  For  this  reason  the  union  operation  should  be 
considered  with  care. 

(♦)  Set  Difference 

The  SET  DIFFERENCE  is  meaningful,  but  there 
could  be  modeling  orobleme.  It  would  be  used  in  finding 
those  blocks  on  a  form  that  are  not  in  common  with  those  on 
another  form,  modeling  constraints  regulre  that  the  block's 


location  information  be  stored  In  the  tuple  and  not  depend 
on  order  in  tne  table, 

(5)  Cartesian  Product 

The  CARTESIAN  product  operation  is 
incorreet  since  the  resulting  table  structure  would  contain 
duplicate  attributes, 

<«)  Intersection 

The  INTERSECTION  operation  is  meaningful, 
but  there  could  be  modeling  problems.  It  would  be  used  in 
finding  those  blocks  on  a  form  that  are  eomaon  with  those  of 
another  form.  Modeling  constraints  regulre  that  the  block's 
location  information  be  stored  in  the  tuple  and  not  depend 
on  order  in  the  table, 

(7)  Quotient 

The  QUOTIENT  operation  is  Incorrect  since 
both  form  tables  will  have  the  same  arlty. 

(8)  Join 

The  join  ooeratlon  is  incorrect  since  the 
resulting  table  structure  will  have  duplicate  attributes. 

(•)  Natural  join 

The  natural  JOIN  operation  is  meaningful, 
bat  duplicates  the  effeet  of  the  INTERSECTION  operation  in  a 
lesa  efficient  manner  and  should  therefore  be  considered 

meaningless. 


d.  Mall  Table  Type  Oparatlona 

(1)  Projection 

The  PROJECTION  operation  la  meaningful  In 
retrieving  the  eontenta  of  aeaaaoe  fleida  for  uae  m  the 
application. 

(2)  Selection 

The  SELECTION  operation  ia  meaningful  in 
retrieving  a  message  for  uae  m  the  application. 

CD  union 

The  UNION  operation  la  meaningful  In  adding 
nev  messages  to  the  meaaaoe  table  by  appending  mallboxea 
together,  but  there  are  modeling  problems.  The  resulting 
mailbox  could  have  more  than  one  message  with  the  same  "Id” 
field.  For  this  reason  the  union  operation  should  be 
considered  with  care. 

(4)  set  Difference 

The  SET  DIFFERENCE  operation  la  meaningful 
in  finding  those  messages  In  one  mailbox  that  are  not  In 
another. 

(5)  Cartesian  Product 

The  CARTESIAN  PRODUCT  operation  la 
incorrect  since  the  resulting  table  structure  will  have 
duplicate  attributes. 

(S)  Intersection 

The  INTERSECTION  operation  Is  meaningful  In 


finding  those  messages  that  are  eommon  to  two  mailboxes. 


(7)  Quotient 

The  QUOTIENT  operation  is  Incorrect  tine* 
both  mall  tablet  are  of  the  sane  arlty. 

(•)  Join 

The  JOIN  operation  it  Incorrect  slnee  the 
resulting  table  structure  will  have  duplicate  attributes, 

(9)  natural  Join 

The  NATURAL  JOIN  operation  is  meaningful, 
but  produces  the  same  effect  as  the  INTERSECTION  ooeratlon 
elth  less  efficiency,  therefore  It  should  be  considered 
meaningless. 

This  section  has  described  the  operational  effects 
of  the  basic  operations  when  used  on  one  or  two  tables  of 
the  same  type.  Figure  4,1,  on  the  next  paoe,  summarizes  the 
findings  of  this  Subsection. 

2.  Intor-Tvpe  Operations 

The  previous  section  covered  the  effects  of  the  five 
binary  operators  when  conducted  on  tables  of  the  same  type. 
This  section  will  cover  these  operators  when  used  only  on 
tables  of  differing  types.  Table  4.2  will  summarize  the 
findings  of  this  Subsection, 
a.  Union 

Slnee  the  union  operation  ean  only  produce  a 
usable  output  table  when  the  structure  of  the  two  tables  are 
identical,  this  binary  operator  eould  only  be  meaningful 
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when  on«  of  the  tablet  «at  a  database  type  that  happened  te 
match  the  structure  of  the  other  table*  Zn  this  spaelal  ease 
the  result  would  be  ■eeninqful,  and  In  all  other  eases  the 
UNION  oeeratlon  Is  Incorrect. 


Table  4.1  -  Intra-Type  Operations. 


TEXT 

DATA 

SPREAD 

FORM 

ELECT. 

OPERATION 

BASE 

SHEET 

GEN. 

MAIL 

1. 

Insert 

M 

M 

M 

N 

M 

2. 

Rodlfy 

M 

M 

M 

N 

N 

3. 

Delete 

w 

M 

N 

M 

M 

4. 

Projection 

N 

N 

N 

w 

M 

5. 

Selection 

C"J 

M 

M 

w 

M 

“ 

Union 

CM] 

M 

CMJ 

1  CM3 

CM] 

7. 

Set 

Difference 

CNJ 

N 

CM] 

C«J 

M 

«. 

Cartesian 

Product 

- 

M 

so 

m 

• 

9. 

Intersection 

IN] 

W 

CM] 

C-3 

M 

10. 

Quotient 

• 

X 

as 

m 

11. 

Join 

- 

M 

• 

- 

• 

12. 

Natural 

Join 

* 

M 

* 

* 

* 

m  ■  operation  Is  meaningful. 

CM]  a  Operation  Is  meaningful,  but  there 
are  modeling  problems. 

-  a  Operation  Is  Incorrect. 

*  a  Operation  meanlnciess  due  to  duplication. 


b.  Set  Difference 

Since  the  SET  DIFFERENCE  operator  ean  only 
produce  a  usable  output  table  when  the  structure  of  the  two 
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tables  ara  Identical,  this  binary  operation  eould  only  be 
meaningful  when  one  of  the  tables  was  a  database  type  that 

hapoened  to  match  the  structure  of  the  other  table.  In  this 

soeelal  case  the  result  would  be  meaningful,  and  in  all 
other  eases  the  SET  difference  operation  Is  lneorreet, 
e,  Cartesian  Product 

The  CARTESIAN  PRODUCT  operator  ean  produce  a 
meaningful  table  structure  for  all  combinations  of  table 

types  that  win  not  result  In  a  table  with  duplicate 

attributes.  The  presence  of  duplicate  attributes  In  the 
resulting  table  would  make  the  CARTESIAN  PRODUCT  operation 
Incorrect, 

d.  Intersection 

Since  the  INTERSECTION  operator  can  only  produce 
a  valid  outout  table  when  the  structure  of  the  two  tables 
are  Identical,  the  operation  would  only  be  useful  when  one 
of  the  tables  was  a  database  type  that  happened  to  match  the 
structure  of  the  other.  In  this  speelal  case  the  result 
would  be  meaningful,  and  In  all  other  eases  the  INTERSECTION 
operation  is  Incorrect. 

e.  Quotient 

The  quotient  operator  can  only  produce  a 
meaningful  output  tabla  when  the  arity  of  the  seeond  table 
is  smaller  than  the  first,  and  all  Its  attributes  are  also 
found  in  the  first  table.  This  would  then  limit  the  type  of 
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the  seeond  table  to  database#  and  than  require  the  proper 
table  structure  tor  the  quotient  operation. 


t.  Join 

Given  the  tact  tnat  the  actual  structure  ot  each 
table  type  is  an  implementation  issue  and  theretore 
variable#  it  is  conceivable  that  all  table  types  eould  have 
at  least  one  eolumn  structure  in  common  with  another  table 
type  and  the  JOIN  operation  would  produce  a  meaningful 
table. 

q.  Natural  Join 

For  the  same  reasons  as  stated  for  the  join 
operation#  it  is  conceivable  the  the  NATURAL  JOIN  operation 
would  produce  a  valid  and  potentially  useful  table. 


Table  4.2  -  Inter  Tyoe  Table  Operations 


TABLE-2 


TEXT 

DATA 

SPREAD 

FORM 

MAIL 

OPERATION 

TABLE-1 

BASE 

SHEET 

(TX) 

(DB) 

(SS) 

(F«) 

(ML) 

UNION 

TX 

♦ 

'T 

«a 

ea 

« 

DB 

? 

♦ 

? 

? 

• 

ss 

m 

f 

♦ 

m 

• 

FN 

m 

? 

m 

♦ 

- 

ML 

* 

? 

m 

m 

♦ 

SET 

TX* 

”? 

m 

m 

m 

difference 

DB 

? 

♦ 

? 

* 

e 

? 

SB 

m 

T 

♦ 

• 

• 

FN 

m 

f 

am 

♦ 

m 

ML 

m 

% 

• 

m 

as 

♦ 

Table  4,2  -  (cent.) 


TABLE-2 


TEXT 

DATA 

SPREAD 

FORM 

NAIL 

OPERATION 

TABLE-i 

BASE 

SHEET 

(TX) 

(OB) 

(SS) 

(FM) 

(ML) 

CARTESIAN 

TX 

♦ 

M 

M 

M 

M 

PRODUCT 

OB 

M 

+ 

M 

M 

M 

SS 

M 

V 

♦ 

w 

¥ 

F* 

M 

M 

M  . 

♦ 

M 

ML 

M 

M 

M 

M 

♦ 

" 

INTERSECTION 

TX 

♦ 

? 

. 

m 

OB 

? 

♦ 

? 

* 

• 

? 

SS 

m 

J 

♦ 

m 

- 

F* 

m 

f 

- 

♦ 

m 

ML 

- 

? 

* 

ae 

* 

OUOTIENT 

TX 

♦ 

? 

- 

. 

m 

OB 

? 

♦ 

1 

• 

? 

? 

SS 

- 

J 

♦ 

m 

F* 

m 

y 

- 

♦ 

m 

ML 

m 

? 

- 

«a 

♦ 

JOIN 

TX 

♦ 

• 

ae 

m 

m 

OB 

? 

♦ 

? 

■» 

• 

? 

SS 

- 

•» 

♦ 

- 

- 

FW 

- 

? 

m 

- 

ML 

• 

? 

- 

- 

♦ 

NATURAL 

TX 

♦ 

? 

m 

. 

m 

JOIN 

OB 

• 

♦ 

? 

? 

? 

SS 

- 

j 

+ 

- 

- 

FM 

- 

? 

- 

♦ 

m 

ML 

- 

? 

- 

m 

♦ 

N  a  Operation  le  potentially  meanlnoful. 

T  «  Operation  could  produce  a  meaningful 
result  but  depends  on  the  database 
table  structure, 

•  a  operation  Is  lneerreet. 

♦  a  intersection  of  sa*e  command,  effects 

covered  In  section  4.B.1  and  Table  4,1, 
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V.  APPLICATION  LEVEL  INTERFACE 

In  the  preceding  chapters  the  structure  of  the 
conceptual  level  of  the  IASS  has  been  covered.  Chapter  3 
discussed  the  table  as  a  common  data  object,  and  Chapter  4 
introduced  the  primitive  operations  allowed  on  the  table. 
This  chapter  will  describe  how  eaeh  of  the  aopileatlon  level 
packages  Interfaces  to  the  conceptual  level.  All  application 
packages  in  the  1*88  must  make  use  of  the  eommon  data  object 
as  an  Important  part  of  their  modeling  effort.  If  the  common 
date  object  een  closely  model  n  given  application,  then 
maximum  use  een  be  made  of  t.-.i  oneeptual  level  in  order  to 
accomplish  the  application's  functions.  However,  if  the 
common  data  object  is  a  poor  model  of  the  aooiicatlon,  then 
the  eoplleatlon  win  have  to  provide  more  of  Its  own  service 
needs  and  therefore  will  create  a  large  application  specific 
series  of  operations. 

In  Chapter  4  the  twelve  basle  primitive  operations  of 
the  conceptual  level  were  discussed,  and  they  are  listed 
again  In  Table  3.1.  These  operations  will  be  discussed  as 
system  level  operations  where  they  are  invisible  to  the  IAS8 
user.  Those  IA88  operations  that  are  visible  to  the  user 
will  be  dlseussed  In  Chapter  8. 

In  Chapter  2  the  basle  user  visible  functions  of  each 
application  were  grouped  Into  six  command  categories) 

•3 
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<Create>,  <Xnsert>,  <Modlfy>,  <Delete>,  <movs>,  and 
<Retrleve>.  when  issued  by  ths  ussr  thsy  will  esuss  ths 
application  to  oertorm  on*  or  Mors  operations  in  support  of 
ths  user.  while  ths  uss  of  ths  eonesotusl  isvsl  by  ths 
sopllestlon  Is  ssnsrally  invisible  to  ths  ussr,  ths  sample 
list  of  lneludsd  opsrstlons  ean  bs  viewed  ss  to  how  thsy 
will  support  ths  six  visible  command  categories. 


Table  5.1  -  Conceptual  Level  Primitive  operations. 


OPERATION 

ABBREVIATION 

1. 

insertion 

I 

2. 

Modification 

M 

a. 

Deletion 

D 

4. 

Projection 

P 

5. 

Selection 

S 

~ 

union 

'"un™ 

7. 

Set  Difference 

SO 

8. 

Cartesian  Product 

CP 

9. 

Intersection 

IS 

10. 

Quotient 

QT 

11. 

Join 

JN 

12. 

Natural  Join 

NJ 

In  ths  following  sections  each  of  ths  five  included 
application  packages  win  be  covered  as  to  use  of  the 
Conceptual  Level  and  their  own  "Workspace”,  What  is  meant 
by  ths  application's  "Workspace”  is  that  part  of  ths 
application  program  where  the  operationally  specific 
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functions  of  tho  application  occur.  This  would  Ineluda 


variables*  constants*  prooran  logle,  buffers*  and  whatever 
other  Implementation  specific  lteas  are  neeessary.  The 
Workspace  is  what  aakes  eaeh  application  unique  to  the  user 
and  Is  the  part  that  oust  be  Inserted  when  a  new  application 
is  added  to  the  ZASS.  Zt  Is  not  the  Intention  of  this 
chapter  to  foeus  on  the  workspace,  so  Its  coverage  will  be 
general  and  brief.  The  orlmary  ooint  o<  interest  will  be  how 
eaeh  application  can  make  use  of  the  conceptual  level. 

Zn  discussing  use  of  the  conceptual  level*  application 
specific  operations  will  be  described  where  each  requires 
the  use  of  one*  or  more*  conceptual  level  operations.  It 
one  application  operation  can  be  defined  in  terms  of  a 
previously  defined  application  operation*  the  previous 
operation  will  appear  in  brackets,  "<>". 

A.  EDZTOR/WORD  PROCESSOR 

As  discussed  in  Chaoter  3*  Section  (A)*  the  Editor/word 
Processor  (E/WP)  presents  the  greatest  modeling  problem  for 
the  conceptual  level.  This  means  that  the  E/wp  will  perform 
the  ealorlty  of  its  operation  In  the  workspace  and  not  at 
the  conceptual  level. 

1,  E/WP  workspace  Operations 

A  largo  number  of  tho  operations  neeessary  to  model 
the  C/WP  will  Mvo  to  be  located  In  the  workspace  area  since 
the  data-tablo  is  a  moor  model  of  text,  some  of  the 


operations  nacassary  at  the  Workspace  level  are; 
reassembling  text  tuples  Into  a  continuous  text  stream, 
keeping  track  of  the  proper  ordering  of  text  tuples, 
performing  string  searches,  block  moves,  and  character 
replacements.  All  operations  for  formatting  and  display 
vlll  be  eondueted  here. 

2.  E/WP  Conceptual  Level  Operations 

Although  there  are  modeling  problems  with  text,  it 
does  not  mean  that  the  E/WP  cannot  make  use  of  the 
conceptual  level.  The  following  operations  use  the 
conceptual  level  but  do  very  little  direct  manipulation  of 
the  text,  since  that  is  performed  in  the  workspace.  The 
operations  themselves  were  chosen  based  on  a  perceived 
minimum  application  need  and  the  ability  to  use  the 
conceptual  level.  This  is  not  a  complete  listina  of 
possible  E/wp  operations  since  that  is  a  very  implementation 
dependent  question, 

a.  Insert  Text  Tuple 

As  the  workspace  finishes  with  enough  characters 
to  constitute  the  "contents"  field  of  a  tuple,  it  will 
determine  the  proper  "id"  field  sequence  for  the  new  tuple 
and  then  issue  an  INSERT  operation  to  place  the  tuple  in  the 
table. 

b.  Set  Text  Tuple 

The  E/WP  must  determine  the  "id”  of  the  next 
tuple  it  needs.  A  selection  is  performed,  based  on  thet  "id" 

M 


field*  The  resulting  tuple  Is  then  DELETE'ed  froe  the 
original  table  end  the  "contents"  field  of  the  result  is 
PROJECT #ed  out  end  pieced  In  the  Workspace, 

c.  Append  Text  Plies 

The  Workspace  will  <Get>  the  lest  tuple  from 
flle-1  end  then  proceed  to  SELECT  eeeh  tuple  from  file-2,  in 
order*  PROJECT'lng  out  the  "contents"  field*  and  place  it  in 
the  workspace.  As  the  worksoaee  gets  enough  characters  to 
make  a  complete  tuple,  It  will  <lnsert>  the  tuple  into  the 
end  of  file-1. 

d.  insert  A  Text  Pile 

The  workspace  will  <Cet>  tuples  from  table-i 
until  it  finds  the  correct  Insertion  point.  Then  all  tuples 
will  be  SELECT'ed  from  table-2*  one  at  a  time,  in  "id" 
order.  The  "contents"  field  of  each  will  be  PROJECT'ed  out 
and  placed  in  the  workspace.  As  the  Workspace  gets  enough 
characters  to  form  a  eomolete  tuple  they  win  be  <Xnserted> 
into  table-1  with  the  proper  "Id"  field.  When  all  tuples 
from  table-2  have  been  copied  Into  table-1*  the  Workspace 
will  <Get>  the  remaining  original  tuples  from  table-1  and 
<Xnsert>  them  back  Into  table-1, 
a.  Delete  To  A  Buffer 

The  Workspace  will  <Get>  tuples  from  the 
referenced  table  and  <Xnsert>  them  back  into  the  table  until 
it  finds  the  point  at  which  the  deletion  is  to  beam.  Prom 
that  point  it  will  continue  to  <Get>  tuples  from  the  table 
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until  It  find*  the  point  at  which  the  deletion  Is  to  stop* 
As  the  workspace  collects  enough  characters  to  form  a  tuple* 
it  will  assign  a  oroper  "Id"  and  INSERT  the  tuple  In  the 
buffer  table.  After  the  stop  point*  the  Workspace  will 
continue  to  <Get>  tuples  from  the  referenced  table,  and  will 
<Insert>  completed  tuples  baek  into  It  until  the  end  is 
reached. 

f.  Copy  To  a  Buffer 

The  workspace  will  <Get>  tuples  from  the 
referenced  table  and  <Insert>  them  baek  into  the  table  until 
it  finds  the  oolnt  at  which  the  copying  is  to  beuln.  From 
that  oolnt  it  will  continue  to  <Get>  tuples  from  the  table 
until  it  finds  the  point  at  which  the  cooyina  is  to  stop. 
as  the  wnrksoaee  collects  enough  characters  to  form  a  tuole 
it  will  <insert>  them,  with  their  original  "id",  back  into 
the  table.  Simultaneously  it  will  INSERT  the  same  tuples, 
with  new  »id"  fields,  into  the  buffer  table.  After  the  stop 
point,  the  workspace  win  continue  to  <Get>  tuples  from  the 
referenced  table,  and  will  <Insert>  completed  tables  back 
Into  it  until  the  end  is  reached. 

The  use  of  the  conceptual  level  by  the  E/wp  is 
summarized  in  Table  5.2. 

8.  DATABASE  MANAGEMENT  SYSTEM 
1.  Oetabsae  workspace 

Since  the  DBMS  peckaoe  is  e  relational  database 
system,  the  user  will  be  permitted  dlreet  eccees  to  the 


conceptual  level  primitive  operations  without  constraint. 
The  user  accepts  complete  responsibility  tor  the  validity 
and  usefulness  of  all  aetlons.  This  means  there  is  little 
need  for  e  workspace  since  the  user  does  just  about 
everything. 
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x  *  Primitive  operation  is  used. 

-  •  Primitive  ooeretlon  is  not  used. 


2.  Patepaae/Conceptual  Level  Operations 

As  stated  above,  the  user  is  permitted  direct  access 
to  all  the  conceptual  level  primitive  operators.  There  are 
no  limits  placed  on  the  user  In  strueturlno  these  operators 
to  produce  e  desired  result.  However,  it  is  obvious  that  In 
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implementation  son*  Issues  trill  be  encountered  that  trill 
plaea  limits  on  tha  user. 

C.  SPREAD-SHEET 

Tha  spraad-shaat  is  vary  similar  to  a  databasa  in  that 
it  storas  the  facts  ralatad  to  a  usar  defined  "real-world" 
situation,  i.a.  it  is  a  model.  Tha  major  difference  is  that 
tha  usar  is  limited  to  the  predefined  retrievals  and 
displays  provided  by  tha  spread-sheet .  The  spread-sheet  has 
control  and  responsibility  for  the  operation,  while  tha  user 
has  responsibility  tor  the  content. 

1.  Soread-gheat  Workspace  operations 

The  workspace  is  responsible  for  use  of  the  spread¬ 
sheet  data  table  since  the  user  does  not  see  or  manloulate 
it  dlreetly.  It  contains  the  logic  necessary  to  interface 
with  tha  usar  and  control  the  display. 

2,  Soraad-ghaat  Conceptual  Level  Operations 

As  tha  usar  issues  application  specific  commands  tha 
workspace  translates  them  into  a  series  of  application  and 
conceptual  level  operations.  The  list  of  included 
operations  cannot  be  elalaed  to  be  definite  or  complete 
because  that  is  an  implementation  issue  and  really  without 
bounds.  However,  the  list  is  considered  to  be  a  workable  set 
of  operations  for  a  representative  spread-sheet  application. 
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a.  Update  Entry  Positions 

The  workspace  oust  knee  m  ehleh  order  entry 
positions  are  to  be  updated,  "roe"  or  "column"  order.  Eaeh 
entry  position  Is  SELECT'ed  In  turn  based  on  Its  "location" 
field#  and  Its  "function"  field  Is  PROJECT'ed  out.  The 
workspace  evaluates  the  contents  of  the  "function"  field, 
and  resolves  references  to  other  entry  positions  by 
SELECT #lno  them  and  PROJECT' lnp  out  the  "value"  field.  When 
the  new  value  Is  finally  computed,  a  MODIFY  operation  Is 
conducted  to  chanae  the  "value"  field.  The  workspace 
continues  until  all  entry  positions  are  updated. 

b.  Make  An  Entry  In  A  Entry  Position 

The  workspace  must  know  which  column  and  row 
entry  position  Is  belna  referenced,  and  the  value  or 
function  to  be  entered.  A  MODIFY  operator  win  be  used, 
based  on  a  condition  statement,  to  find  the  tuple  with  the 
proper  "location"  entry  and  then  chance  Its  "function”  and 
"value"  field.  If  the  Spreadsheet  Is  In  automatic 
recalculation  made,  than  related  entry  positions  win  have 
to  be  <Updated>. 

c.  Add  A  sew  Column  Or  Row 

The  workspace  must  know  the  eoiumn  or  row  on  the 
spreadsheet  that  Is  being  referenced  and  where  the  new 
column/row  la  to  be  Placed  relative  to  It.  The  modify 
operator  will  be  used  to  find  those  entry  positions  that 
must  be  moved,  and  chanoe  their  "location”  and  "function” 
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fields  to  take  Into  account  the  shift  in  position.  New 
tuples*  with  "locution"  fields  corresponding  to  the  added 
row/eolumn  will  be  INSERTED,  Lastly*  all  entry  positions 
will  be  <Uodated>, 

d.  Delete  A  Column  Or  Row 

The  workspace  must  know  the  eoiumn  or  row  on  the 
spread-sheet  that  is  being  referenced.  A  DELETION  operator 
is  Issued  with  a  condition  statement  corresoondlna  to  the 
proper  "location".  Next*  a  MODIFY  operation  Is  conducted  on 
the  "location”  field  of  the  proeer  entry  positions  necessary 
to  close  the  resulting  gap,  Lastlv*  all  entry  positions  will 
be  <Updated>, 

e.  Append  Spread-Sheets 

The  workspace  must  know  whether  sheet-2  is  to  be 
appended  to  the  side  or  bottom  of  sheet-l.  Given  that 
information*  a  SELECTION  is  dene  on  sheet-1  to  find  the 
maximum  "location"  field  and  it  is  PROJCCT'ed  out  and  saved 
in  the  workspace,  a  MODIFY  operation  is  next  conducted  on 
all  tumies  in  sheet-2  to  add  the  proper,  row  or  eoiumn* 
value  saved  above  to  all  entry  position  references  in  the 
"location"  and  "function"  fields  of  sheet-2.  Sheet-2  is 
then  UNiON'ed  to  sheet-1*  and  the  resulting  sheet  is 
<Updated>, 

f.  Spread-Sheet  Intersection 

Given  that  you  want  to  display  the  common  entry 
positions  of  sheet-l  and  sheet-2t  Perform  the  INTERSECTION 
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operation  between  sheet-1  ond  sheet-2.  Then  <Updoto>  tho 
resulting  table. 


9.  Spread  Sheet  SET  DIFFERENCE 

Given  that  you  want  to  dlaply 
positions  that  are  unique  to  sheet-i  and 
shaet-2!  Perform  the  SET  DIFFERENCE  between 
sheet-2.  Then  <Update>  the  resulting  table. 


those  entry 
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Table  5.3  -  Spread-Sheet  Interface. 
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X  •  Primitive  operation  is  used. 
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The  use  of  the  conceptual  level  by  the  Spread-Sheet 
application  Is  s«p«arlsed  in  Table  5.3. 
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0.  FORM  GENERATOR 


Zt  it  the  purpose  of  the  Fern  Generator  to  ereete  e 
table  that  will  be  used  at  a  later  tine  In  support  of  other 
epplleatlen  packages  or  the  user  dlreetly.  The  Form  table 
is  probably  the  most  complex  table  of  the  five  included  in 
the  IASS  'since  it  will  be  called  on  to  do  so  much.  The  table 
reads  like  a  set  of  step  by  step  Instructions  on  how  to 
Input  or  output  the  provided  data.  As  this  is  a  heavily 
impicsiantetlon  dependent  application,  not  much  emphasis  will 
be  placed  on  specific  uses. 

1.  Form  Generator  workspace  Operations 

The  workspace  In  the  Form  Generator  must  be  fairly 
lntellloent  since  It  has  two  modes  of  operation.  The  first 
Is  "deslan-tlme"  when  It  must  Interpret  the  user  commands 

ft 

Into  a  series  of  block  entries  In  the  form  table.  The  second 
Is  "use-time"  when  It  must  use  the  Information  In  the  table 
to  create  the  desired  output  form.  This  reoulres  that  the 
application  logic.  Its  ability  to  Interface  to  the  other 
applications,  and  any  needed  structures  be  contained  in  the 
workspace, 

2,  Form  Generator  Conceptual  Level  Operations 

The  Fora  Generator  does  little  more  than  build  the 
table  at  "design"  time,  and  read  the  Instructions  In  the 
table  at  "use"  time.  Zt  therefore  seems  that  It  ean  make 
fairly  extensive  use  of  the  conceptual  level  operators. 
However,  a  complete  list  of  all  possible  oeeretlons  Is 


impossible  since  the  Perm  Generator  application  teams  to  be 
the  most  Implementation  dependent  application  of  all.  The 
list  of  operations  that  follows  Is  Intended  as  a 
representative  droop  of  basle  operations  and  Is  not 
definitive. 

a.  Clear  workspace 

If  the  workspace  is  empty,  then  do  nothing* 
However*  if  there  are  entries  In  the  workspace  then  issue  a 
MODtfT  operation,  based  on  "location”,  to  chance  those 
fields  that  have  entries.  If.  no  block  was  found,  then  Issue 
an  INSERT  operation  to  plaee  the  block  In  the  table. 
Lastly,  erase  the  workarea. 

b.  rind  Bloek 

first.  <Ciear>  the  workspace.  Use  a  SELECTION 
operation  to  find  the  new  block  being  referenced.  PROJECT 
out  the  "location"  field,  and  any  other  fields  that  are 
needed.  If  no  block  was  found,  then  wait  for  next  user 
commend* 

c*  Add  A  New  Bloek 

The  workspace  must  start  blank  since  It  cannot 
have  found  a  referenced  block  where  a  new  bloek  Is  being 
added*  The  user  enters  the  proper  Information  Into  the 
workspace  and  when  the  user  Is  finished,  the  workspace  will 
be  <Cloarod>* 
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d.  Edit  A  Block 

When  th«  user  edits  an  already  existing  block 
then  It  will  have  been  found  by  the  "Find  Referenced  Block" 
operation  described  above.  The  workspace  will  wait  until  the 
o«er  is  finished  editing,  and  then  <Ciear>  the  workspace. 

e.  Delete  A  Block 

<ciear>  the  workspace.  Issue  a  DELETE  operation 
based  on  the  user  generated  condition, 

f.  Append  rorms  Together 

<Clear>  the  workspace.  Given  that  form-2  is  to 
be  appended  to  the  bottom  of  for»-l*  Use  the  SELECT 
operation  to  find  the  block  with  the  highest  row  number  and 
lowest  eolumn  number  In  for»-i.  PROJECT  out,  and  save  in 
the  workseaee,  the  "row"  field.  Issue  a  kooiry  operation  on 
all  blocks  In  form-2,  and  add  the  saved  "row"  number  from 
form-1  to  the  "row"  field  In  form-2.  Then  union  form-2  to 
form-i. 

g.  Add  A  Blank  Line  To  The  Form 

The  workspace  must  know  the  referenced  row 
number  on  the  form.  Clear  the  workspace.  Issue  a  MODIFY 
operation  on  all  blocks*  on  or  below  the  referenced  row,  to 
uedete  their  "location"  field. 

h.  Form  Intersection 

Given  that  the  desired  display  la  those  bloeks 
that  are  found  both  in  fore-1  and  for«-2,  first  <Clear>  the 
workspace. 
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If  position  on  the  for*  is  Important!  Psrform 
ths  INTERSECTION  operation  on  formal  and  form-2.  Pass  the 
rasuitlnq  tabls  to  tha  HorKspaea. 

If  position  on  tha  form  Is  not  Important! 
PROJECT  out  tha  "promot",  * i/o ",  and  "function*  flalds  of 
form-l  and  form-2.  Do  an  INTERSECTION  oparatlon  on  tha  new 
tablas  and  than  natural  JOIN  tha  rasuit  to  tha  original 
tabla-l.  mass  tha  rasuitlnq  tabla  to  tha  Workspace. 

1.  Perm  Sat  Difference 

Given  that  the  desired  display  is  those  blocks 
In  form-1  that  are  not  found  in  form-2,  first  <Clear>  the 
workspace. 

If  oositlon  on  tha  form  is  Important!  Perform 
the  SET  DIFFERENCE  between  form-1  and  form-2.  Pass  tha 
rasuitlnq  tabla  to  tha  Workspace. 

If  position  on  tha  form  Is  not  important! 
PROJECT  out  tha  "prompt",  "l/o",  and  "function"  flalds  of 
form-t  and  form-2.  Perform  tha  SET  DIFFERENCE  between  these 
rasuitlnq  tables.  Taka  this  rasuit  and  natural  join  it  to 
tha  orlqlnal  tabla-l.  Pass  tha  rasuitlnq  tabla  to  tha 
workspace. 

Tha  use  of  tha  conceptual  level  by  tha  Form 
Generator  application  Is  summarized  In  Table  S.4. 


Table  5.4  •  Fora  Generator  interface 
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X  ■  Primitive  operation  Is  used. 
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E.  ELECTRONIC  MAIL 

The  purpose  of  the  Mall  application  is  to  enable  the 
user  to  leave  oessaoes  for  other  users  who  are  not  presently 
available.  Aoain  this  is  a  very  lepleaentatlon  dependent 
application  in  deterainlno  exactly  what  services  you  wish  to 
provide.  As  before,  lepleaentatlon  issues  will  be  avoided  as 
ouch  as  possible. 
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1*  Electronic  Mali  workspace  Ogtritloni 

The  Workspace  is  responsible  for  translating  user 
eoaaands  into  application  operations  necessary  to  create  and 
read  passages.  It  contains  the  logic  neeessary  to  use  the 
Mall  table.  Interpret  user  commands,  and  control  the 
display. 

2.  Electronic  Mall  Conceptual  Level  Operations 

A  fairly  wide  range  of  application  operations  ean  be 
accomplished  by  using  the  conceptual  level  operations, 
while  the  following  list  of  operations  eannot  be  considered 
complete  or  definite,  it  is  representative  of  an  Electronic 
mall  application. 

a.  Pickup  Mall 

Upon  entering  the  IASS,  the  nail  system  is 
automatically  directed  to  plcieup  any  mall  for  the  user.  The 
mail  system  generates  a  SELECTION  operation  on  the  system 
mailbox  with  the  condition  that  the  oessage(s)  is  addressed 
to  the  user.  The  resulting  table  is  SET  DIFPERENC'ed  with 
the  system  mailbox  and  then  UNlON'ed  with  the  user's 
mailbox. 

b.  dead  Mall 

The  workspace  oust  have  an  "id"  of  the  desired 
message.  A  SELECTION  operation  is  performed  on  the  user's 
mailbox  based  on  the  ”ld"  field.  The  subparts  of  the 
message  are  PftOJECT'ed  out  and  eiaeed  in  the  workspace. 


c.  Find  Mall 

Given  a  user  entered  condition  statement  the 
werkarea  will  generate  a  SELECTION  operation  based  on  that 
condition.  The  proper  fleld(s)  of  the  messages  will  be 
PROJECT'ed  out  and  placed  in  the  workspace  to  support  an 
appropriate  display. 

d.  Edit  A  Message 

The  Workspace  will  know  the  "Id"  of  the  message 
being  edited,  when  the  user  is  completed,  a  modify  operation 
will  be  Issued  based  on  that  "Id”  to  ehange  any  fields  that 
were  edited.  If  no  message  with  that  "Id”  was  found  by  the 
MODIFY  operation  then  It  must  be  a  newly  created  message  and 
the  Workspace  will  INSERT  It  into  the  user  mailbox. 

e.  Delete  Mail 

The  workspace  will  know  the  "Id"  of  the 
■essage(s)  or  be  given  a  user  defined  condition  statement. 
Based  on  tr.jse,  a  DELETION  operation  win  be  performed  on 
the  user's  mailbox. 

f.  Multi-hat 

Given  that  the  workspace  has  a  single  message 
with  a  multi-hat  destination!  PROJECT  out  the  contents  of 
the  "to"  field  in  the  message,  and  plaee  It  In  the 
workspace.  The  workspace  will  find  a  database  "alias"  table 
with  that  naaa  which  has  "id"  and  "to”  fields.  The  tuples  In 
this  table  correspond  to  the  actual  names  in  the  multi-hat 
name.  Taking  the  original  message.  PROJECT  out  the  "from". 
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"subj",  "date",  and  "body"  fields.  Taiet  the  result  and 
earfora  a  cartesian  PRODUCT  with  the  alias  tabic.  Now  union 
t*e  results  with  the  system  mailbox, 
q.  Send  Mall 

Each  tine  the  user  leaves  the  Mall  application, 
any  outgoing  mall  is  automatically  sent.  The  workspace 
generates  a  SELECTION  based  on  the  condition  to  find  all 
messaoes  not  addressed  to  the  user.  The  resultina  "outgoing" 
table  is  SET  PtrrERENC'ed  with  the  user's  mailbox.  A 
SELECTION  is  then  performed  on  the  outgolno  table  to  find 
any  multi-hat  destinations .  The  resulting  multi-hat  table  is 
SET  DIFFERENC'ed  with  the  outgoing  table,  and  the  remaining 
outgoing  messaoes  are  UNlON'ed  with  the  system  mailbox.  The 
messaqes  in  the  multi-hat  table  are  then  SELECT'ed  one  at  a 
time.  DELET'ed  from  the  multi-hat  table,  and  then  processed 
by  the  <Multl-Hat>  operation, 
h.  Mall  Synoosls 

PROJECT  out  the  "from",  "to",  and  "subject" 
fields  of  all  the  messages  in  the  user's  mailbox.  The 
workarea  will  use  this  new  table  by  SELECT'lng  each  message 
in  "id"  order,  PROJECT'ing  out  the  three  fields,  and  using 
the  results  to  ereate  the  display. 

The  use  of  the  conceptual  level  by  the  Mall 
application  Is  summarized  in  Table  5.5. 


1 


Table  5.5  -  Mall  Intersection. 


PRIMITIVE  OPERATIONS 


OPERATION* 

I 

"m" 

D 

S 

UN 

"SD 

CP 

is 

"qt 

JN 

NJ 

a. 

Plekup 

. 

m 

"I" 

"x" 

X 

'x 

m 

m 

• 

• 

m 

b. 

Read 

• 

m 

- 

X 

X 

ms 

aw 

m 

m 

m 

m 

am 

c. 

Find 

• 

m 

- 

X 

X 

• 

- 

as 

m 

m 

m 

am 

d. 

Edit 

X 

X 

- 

- 

- 

• 

- 

• 

me 

m 

m 

m 

e. 

Delete 

as 

me 

X 

m 

m 

m 

- 

m 

m 

m 

m 

as 

f. 

multi- 

Hat 

• 

m 

•a 

X 

• 

X 

- 

X 

m 

m 

m 

m 

g. 

Send 

m 

am 

X 

X 

X 

X 

X 

X 

m 

m 

m 

m 

h. 

Synopsis 

- . 

m 

- 

X 

X 

m 

m 

ms 

am 

m 

m 

m 

USED 

T 

T 

T 

”x" 

"x" 

T" 

"x"' 

"x 

m 

• 

m 

- 

X  *  Primitive  operation  Is  used. 

«  •  Primitive  ooeratlon  Is  not  used. 


The  results  of  the  preceding  five  sections  are 
summarized  In  Table  5,6.  It  shows  that  the  application 
packages  can  make  extensive  use  of  the  majority  of  the 
primitive  operations  found  at  the  conceptual  level.  This 
chapter  has  not  tried  to  show  all  the  possible  application 
operations  and  their  use  of  the  conceptual  level.  Instead  a 
fairly  representative  and  basle  set  of  operations  was 
dlseussed.  The  actual  list  of  operations  included  in  each 
IASS  application  will  be  a  very  Implementation  dependent 
issue. 


4 
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Tabic  5.6  -  Application  Intersection  overview 


PRIMITIVE  OPERATIONS 

APPLICATION 

I 

T 

— 

P 

s 

UN 

SD 

CP 

IS 

QT 

JN 

NO 

1. 

ED  6 

WP 

X 

m 

m 

X 

X 

m 

X 

• 

m 

m 

2. 

DBMS 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

3. 

Spread 

Sheet 

X 

X 

X 

X 

X 

X 

X 

• 

X 

• 

m 

Form 

Gen. 

X 

X 

X 

X 

X 

X 

X 

m 

X 

m 

m 

X 

5. 

"all 

X 

X 

X 

X 

X 

X 

X 

X 

m 

■ 

• 

m 

TOTAL 

5 

T 

T 

T 

5 

4 

..... 

"1 

i' " 

..... 

T 

~ 

X  *  Primitive  operation  Is  used. 

-  *  primitive  operation  Is  not  used. 
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VI.  USER  INTERFACE 


The  Integrated  Application  Software  System  (IASS) 
combines  the  capabilities  of  the  five  software  application 
packages  described  in  Chapter  2.  Each  of  these  applications 
performs  a  set  of  functions  on  an  associated  logical  file 
type.  Integration  of  these  distinct  systems  is  brought 
about  by  determining  the  set  of  common  functions  performed 
by  each  system  on  the  associated  logical  file  type,  defining 
a  eommon  data  object  to  represent  the  logical  file  types, 
and  finally  defining  a  system  of  primitive  operations  on  the 
eommon  data  objeet. 

The  previous  chapters  have  covered  the  integration 
approach  at  the  system  level,  where  it  is  invisible  to  the 
user.  Another  integration  level  is  vital  to  the  IASS  design 
and  it  must  occur  where  the  user  interfaces  to  the  iass's 
applications.  The  result  of  integration  at  the  user 
interface  will  be  a  system-wide,  common  set  of  user 
operations  and  associated  commands,  and  a  regular  display 
organisation  of  the  logleallv  distinct  file  types  at  the 
user  Interface.  This  is  probably  the  most  important  command 
interface  since  it  is  the  one  vthe  user  ean  actually  perceive 
and  evaluate. 

Implementation  of  the  IASS  requires  designing  for  one 
conceptual  display  model  using  a  single  physical 


organizational  schema.  The  IASS  will  therefore  ensure 
minimal  system  complexity  at  both  the  user  and  system 
interface.  The  basle  IASS  hierarchy  is  depicted  in  Figure 
6.1. 


Figure  6.1  -  xass  Hierarchy 
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A,  USER  INTERFACE  MODULE 


Th«  interface  between  the  user  and  the  system  eouples 
the  user  to  the  applications  of  tha  IASS,  and  allows  eontrol 
of  the  oporstlon  of  the  system.  Tho  usor  Zntorfseo  Modulo 
(UIM)  is  an  abstraction  to  contain  the  features  of  the  IASS 
which  the  user  can  assume  are  present  in  any  context  of 
system  use.  The  UIM  encompasses  both  the  environmental  and 
operational  assumptions  of  the  system. 

The  UIM  is  not  a  stand-alone  entity.  It  depends  heavily 
on  each  application  program  to  interpret  the  user  input,  and 
to  determine  tne  appropriate  display  structure.  It  is  the 
application  program  that  translates  the  common  UIM  commands 
into  a  series  of  application  operations  that  may,  or  may 
not,  maiee  use  of  the  conceptual  level, 

1.  UIM  Display  Format 

The  point  of  observation  of  the  system  is  the 
terminal  screen,  which  is  a  finitely  dimensioned  "window” 
into  the  logical  file  or  data  object  in  reference.  For  ell 
applications  the  display  size  is  not  limited  to  the  size  of 
the  screen  window.  If  the  display  is  large,  the  user  will  be 
able  to  use  the  UIM  to  maneuver  the  window  over  the  display 
to  accomplish  the  desired  tasks.  The  UIM  does  not  eontrol 
the  type  of  display  presented  to  the  user,  since  this  is  an 
application  dependent  requirement.  However,  the  UIM  does 
give  the  user  a  consistent  method  of  interacting  with  the 
display  as  the  applications  change. 


•  • 
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2.  UIM  Command  Ling 


The  UIM  uses  a  common  display  organization  which  Is 
augmented  by  tha  specific  application  program  In  use.  In  any 
context  of  use,  tha  top  lino  of  tha  screen  is  dedicated  for 
presentation  of  the  UXM  command  line.  The  next  line  will 
always  be  used  by  the  application  program  for  Its  command 
line.  in  this  manner,  the  top  two  lines  of  the  screen  will 
always  contain  system  Information  and  Prompts  for  the  user. 

3.  UIM  Editing 

From  the  results  of  the  requirements  analysis  phase 
of  this  study,  the  function  which  is  common  to  each  utility 
is  that  of  making  changes  to  a  referenced  file,  l.e, 
editing.  All  the  UIM  really  provides  the  user  with  is 
screen  edltlna  features.  Xt  will  be  the  application  program 
that  Interprets  the  UIM  commands  into  more  complex 
operations.  Editing  should  be  done  on-screen,  with 
immediate  feedback  available  to  the  user.  For  user 
protection,  all  editing  will  be  done  on  a  cooy  of  the 
designated  file  and  only  committed  as  a  permanent 
modification  when  explicitly  directed  by  the  user.  The 
common  set  of  editing  commands  provided  by  the  UTM  may  be 
augmented  by  functions  from  the  underlying  application 
program  to  ensure  that  speelal  editing  aetlons,  which  are 
specifically  associated  with  a  logical  file  type,  are 
executable. 


I* 


4.  UXM  Commands 

The  operational  assumptions  of  tha  IASS  UXM 
eoaproalsed  a  sat  of  osar  commands.  Those  commands  ean  be 
assumed  to  produce  a  similar  offset  when  executed  In  any 
context  of  system  uae.  It  is  the  purpose  of  eaeh  application 
to  provide  the  appropriate  translation  between  the  UI* 
commands,  the  dlseiay  of  the  data  object,  and  Its  conceptual 
representation. 

Based  on  the  eateaorles  of  commands  defined  In 
Chanter  2,  there  are  three  major  categories  of  commands  In 
the  UXM,  The  first  Is  "Movement11  commands  that  control  the 
position  of  the  cursor  on  the  screen,  and  the  location  of 
the  sereen  In  reference  to  the  application  display.  The 
second  category.,  Is  "Editing"  commands  that  make  additions, 
deletions,  and/or  changes  to  the  data  in  the  display.  The 
third  category  Is  "System"  commands  that  are  not  used  by  the 
application,  but  by  tha  IASS  to  perform  its  "housekeeping" 
functions.  There  are  many  different  methods  for  attemotlng 
to  present  tnese  categories  to  the  user,  and  they  are  all 
Implementation  dependent.  For  the  purpose  of  this  thesis  a 
possible  listing  of  standard  UXM  commands  is  given  In  Table 
4.1. 

All  of  the  besle  categories  presented  In  Chapter  2, 
with  the  exemption  of  the  <Modlfy>  command,  are  directly 
implemented  by  UXM  commands.  There  did  not  seem  to  be  any 


simple  way,  short  of  accepting  a  complex  command  syntax,  to 
implement  ona  UIM  command  par  eateqory. 


Table  6.1  •  UIM  c 


UIM 

CATEGORY 

UIM 

COMMAND 

CHAPTER  2 
CATEGORY 

Movement 

1. 

Move  cursor 

-  right 

-  left 

-  up 

-  down 

-  top  of  screen 

-  bottom  of  screen 

-  start  of  file 
•  end  of  file 

Move 

2. 

Seroli  screen 

-  riqht 

-  left 

-  up 

-  down 

Move 

Editing 

3, 

rind  Object 

Move  & 
Retrieval 

4. 

Insert  Object 

Insert 

5. 

Copy  Object 

Insert 

6. 

Add  Objeet 

Insert 

7. 

Move  Objeet 

Delete  6 
Insert 

8. 

Delete  Objeet 

Delete 

System 

9. 

Enter  Application 

Create 

10. 

Output 

Retrieval 

11. 

Save  Changes 

- 

12. 

Quit  Application 

m 

Tha  <Modlfy>  eataqory  did  not  naad  a  eoaaand  of  Its  own 
beeausa  it  baeaaa  apparent  that  tha  application  itself  will 
be  able  to  dataralna  when  modification  is  naeassary  based  on 
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us*  of  th*  UIM,  In  Soetlon  (B)  whleh  follows,  ooeh  of  tht 
flvo  opplleotlons  will  bo  covered  with  th*  intention  of 
showing  how  they  uso  tho  standard  UXM  commands  to  Implement 
tho  eoooond  categories  of  Chester  2. 

B.  APPLICATION  PROGRAM  LEVEL 

The  Applieetlen  Program  Level  (APL)  consists  of  the 
actual  aoolleatlen  programs  that  interface  to  the  user 
through  the  UIM,  and  operate  on  the  common  data  object  by 
the  primitive  operations  available  at  the  conceptual  level. 
Each  application  program  has  a  specific  user  support 
function  and  although  It  uses  the  common  UIM  it  has  eertaln 
features  that  make  It  unique.  Each  of  the  IASS  application 
oroarams  will  be  discussed  In  the  following  sections. 

Pour  areas  of  each  application  will  be  discussed. 
First,  the  display  format  used  by  each  application  to  take 
advantage  of  tn*  features  of  the  UXM.  since  the  screen  win 
be  th*  common  lnout/output  medium  for  the  IASS  it  Is 
important  that  the  perceived  use  of  the  display  be  similar 
between  applications.  Second,  the  editing  features  of  the 
application.  Again,  as  this  is  part  of  th*  common  Interface 
medium  for  th*  IASS  it  Is  Important  that  th*  user  perceive  e 
similarity  between  editing  features  in  each  application. 
Third,  specialised  "functions”  of  th*  application.  These 
are  the  unique  features  of  each  application  that  will 
differentiate  them  from  other  included  applications. 


Fourth,  uso  of  the  standard  UXM  commands  by  tho  application. 
This  will  show  how  tha  application  will  usa  a  standardized 
command  to  perform  an  application  specific  operation, 
l.  i*S8  Editor/Word  Processor 

Tha  IASS  text  table  is  not  limited  by  dasian  to 
supporting  any  one  type  of  editor  and  word  processor 
arrangement.  However,  as  was  pointed  out  previously,  the 
on-screen  editor  with  on-line  formattlna  is  rapidly  becoming 
the  accepted  standard  and  any  regression  to  line  oriented 
editors,  or  the  like,  would  meet  with  serious  user 
resistance.  For  this  reason  an  on-screen  editor  with  on¬ 
line  formatter  is  assumed, 

a,  e/wp  Display  Format 

The  Editor/word  Processor  (E/WP)  has  a  single 
display  called  "page"  format,  and  Figure  6.2  provides  an 
illustration.  The  screen  represents  a  window  over  the  sheet 
of  paper  on  which  the  text  is  being  written,  wnat  the  user 
sees  through  the  window  is  the  format  that  will  actually  be 
output.  The  default  Word  Processor  (WP)  settings  will  natch 
the  size  of  the  C/WP  display  to  the  size  of  the  screen  (l.e, 
no  part  of  the  text  win  be  hidden  off  either  side  of  the 
screen).  However,  the  user  is  free  to  issue  wp  commands  that 
will  result  in  a  display  larger  than  the  screen.  In  this 
ease  the  user  will  have  to  use  cursor  movement  commands  to 
bring  the  off-sereen  portions  into  view. 


iuser  entered  command)  R»f  C«#  (Textfiie  Name) 

...*....2....*....3....*....4....*....S....*....6. 

If  you're  not  using  the  standard  library,  or  If 

will  nave  to  construct  calls  to  other  programs  usi 
•  • 

(through  temporary  files.  Hare  it  is  natural  to  makl 

Figure  6,2  -  "Paae"  Display  Format  for  Editor/word 

Processor. 

(Display  size  is  larger  than  sereen  size.) 

b.  E/WP  Editing 

All  text  files  make  use  of  the  word  Processor 
(wpj,  and  it  is  always  on-line.  At  entry  the  WP  is  set  to 
certain  default  output  values  tor  page  length,  line  size, 
line  soaeino,  left  margin,  right  margin,  and  tab  size.  The 
user  can  aceept  these  default  settings  or  can  issue  commands 
to  the  E/wp  to  change  them.  The  E/wp  continuously  scans  the 
text  stream,  recognizes  the  commands,  and  immediately 
changes  the  output  format. 

Editing  is  accomplished  by  positioning  the 
cursor  at  any  oolnt  on  the  sereen  and  typing  in  an  entry. 
The  entry  is  Inserted  between  the  present  contents  of  the 
location.  Deletion  and  modification  are  accomplished  in  a 
similar  on-screen  manner,  only  commands  that  make  use  of 
largo  objects,  like  blocks  or  other  files,  need  resort  to  a 
command-lino  format.  As  the  E/wp  formatter  is  always  on- 
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lint,  tht  uttr  does  not  htvt  to  worry  about  starting  now 
lints,  indenting,  lint  spacing,  now  paqt,  and  othtr  similar 
format  eonsldarations •  Tht  E/WP  automatically  dots  it  for 
tht  ustr,  but  tht  ustr  ean  still  taiet  manual  control  if 
rtauirtd. 

To  assist  tht  ustr  in  certain  editing  situations 
tht  E/wp  win  provide  a  certain  number  of  buffers  for  the 
user  to  treat  as  temporary  storaae  areas,  actually  they  are 
temporary  text  files  created  by  the  E/wp  and  are  destroyed 
when  tne  session  is  ended. 

The  E/wp  actually  operates  on  a  copy  of  the 
orioinal  file,  so  any  changes  made  during  a  session  only 
become  permanent  *»hen  the  user  issues  a  "save"  command.  If 
the  user  quits  without  saving,  then  it  is  as  if  the  session 
never  occurred. 

c.  E/wp  Functions 

Cl)  Formatting  Commands 

s  series  of  specialized  word  Processing 
commands  must  be  Included  in  the  C/WP  application  to  allow 
the  user  to  modify  the  format  of  the  text.  These  commands 
must  be  structured  in  such  a  way  so  that  they  are  readily 
distinguished  in  the  text  stream  and  will  not  be  mistaken 
for  text. 
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d,  K/WP  Commands 

(1)  rind 

U««d  to  locate  character  or  string  sized 
objects  specified  by  the  user.  The  located  object  is 
displayed  by  scrolling  the  window  to  Its  location,  and  the 
user  Is  notified  if  another  natch  exists.  This  operation 
will  use  a  command- line  format. 

(2)  Insert 

Used  to  plaee  any  valid  object  at  a  point 
referenced  by  the  cursor.  The  present  contents  are  not 
overwritten,  merely  pushed  aside  to  make  room  for  the  new 
object.  This  operation  will  use  an  on-screen  format.  Zt  is 
possible  to  Insert  larae  objects,  such  as  buffers  or  other 
text  flies.  Into  the  file  being  edited,  but  this  win 
reouire  the  use  of  a  command-line  format. 

(3)  ove 

Used  to  change  the  location  of  line  or 
bloek  size  objects  specified  by  the  user.  The  objeet  Is 
deleted  from  its  eresent  location  and  then  Inserted  In  the 
new  location.  This  operation  will  require  the  use  of  a 
command-line  format. 

(4)  heists 

Used  to  remove  any  objaet  (character,  line, 
block)  specified  by  the  user.  The  objeet  Is  normally  not 
saved,  but  if  the  user  specifies  It  can  be  saved  in  e 
buffer.  This  operation  will  require  the  use  of  both  on¬ 
screen  end  eomaend-llne  formats. 
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(5)  Copy 


Used  to  duplicate  an  object  and  then  insert 
the  duplicate  at  a  specified  eursor  location  or  Into  a 
buffer.  This  operation  will  require  the  use  of  a  command- 
line  format, 

(6)  Add 

Used  to  create  a  blank  line(s)  on  the 
display,  above  or  below  the  cursor  position.  This  operation 
will  require  the  use  of  an  on-screen  format, 

(7)  Output 

Used  to  send  the  file  to  some  designated 
output  device.  The  output  format  of  the  file  will  exactly 
match  the  format  seen  on  the  dlsolay  during  editing, 

2.  IASS  Database  management  System 

The  main  Intention  of  the  Database  management  System 
(DBMS)  Is  to  emphasize  simplicity.  It  does  not  make  sense 
to  follow  the  lead  of  many  currently  available  OBMS  packages 
that  add  large  amounts  of  complexity  to  gain  minor  and 
seldom  used  capabilities. 

a.  DBMS  Display  Format 

There  will  be  two  formats  In  which  database 
tables  will  be  displayed.  The  first,  and  default  format  Is 
called  "table".  The  table  will  be  displayed  In  a  tabular, 
row  and  column,  format  for  the  user  to  edit.  Figure  6.3 
illustrates  the  "table"  display  format. 
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Flours  6.3  •  "Table"  Dlsolav  Format  for  DBMS-Table. 


The  second  foraet  will  be  "page",  and  It 
displays  the  records  In  a  vertical  format  with  no  portion  of 
the  table  lying  off-screen  to  the  sides. 


laser  entered  command!  R«»  c«l  (Database  Name! 
(prompt!  Fit  *••§•  (Table  name! 


Name 

UN 

Age 

Dept 


i 


i 


Comments  t 


Floors  1.4  -  "Face"  Display  Format  for  DiNi-table 


Instead,  aaeh  field  hes  et  least  one  line  on  which  to 
display  Its  contents,  end  een  have  aore  then  one  line  If 
needed.  The  user  will  scroll  in  e  vertical  direction  to 
view  the  entries  In  the  table.  Pleura  6.4  Illustrates  the 
•pace"  forest. 

b.  DBMS  Editing 

The  DBMS  makes  use  of  the  UXM  described  In 
section  (A),  above.  However  there  are  so«e  constraints.  The 
user  is  not  free  to  write  anywhere  on  the  screen,  but  Is 
limited  to  writing  within  field  positions.  Field  positions 
are  the  bounded  locations  at  column  and  row  intersections 
for  the  "table"  dlsolav,  and  the  locations  between  the 
delimiters  "t"  for  the  "page"  display.  Entries  cannot  be 
made  to  pass  throuoh  field  boundaries,  and  the  user  will  be 
prompted  if  It  is  attempted.  To  cross  sueh  boundary 
reoulres  the  use  of  e  cursor  motion  command. 

The  DIM  commands  will  be  used  to  edit  the 
displayed  table.  Cursor  motion  keys  will  be  used  to 
position  the  cursor  In  a  valid  field  position.  Text  win  be 
inserted,  or  deleted,  Inside  the  field  position.  The  user 
will  be  allowed  to  scroll  across  the  sereen  In  ell  four 
directions,  op  to  the  Unit  of  the  size  of  the  table. 

Records  ere  added  to  the  table  by  editing  a 
"blank"  tuple.  Blank  tuples  ere  found  automatically  at  the 
end  of  the  table  display,  or  created  by  using  the  "add" 


command  to  Insert  thou  above,  or  below,  tho  present  cursor 


position, 

Tho  IASS  provisos  o  degree  of  orotoetlon  to  tho 
usor  In  thot  nono  of  tho  editing  ehongos  (record  Insertions, 
itod If leetlons,  or  deletions)  are  made  until  the  user  loses  e 
"save"  comnend.  At  that  tlee  the  original  table  Is  removed 
end  the  copy  on  which  the  editing  was  done  takes  Its  oiece. 
If  the  user  cults  without  savino,  then  none  of  the  edltlna 
changes  are  made. 

c,  obms  Functions 

(1)  Relational  Operators 

The  following  relational  operations 
described  in  Chapter  4,  Section  (a)  are  available  to  the 
user  In  the  DBMS,  The  operators  arei  modification,  deletion, 

PROJECTION,  SELECTION,  UNION,  SET  DIFFERENCE,  CARTESIAN 
PRODUCT,  INTERSECTION,  QUOTIENT,  JOIN,  and  NATURAL  JOIN. 
The  INSERTION  operation  Is  not  Included  since  It  Is  already 
performed  by  the  uim,  end  the  MODIFICATION  and  DELETION 
ooerends  ere  for  mess  operations  where  using  the  uim 
modification  and  deletion  capabilities  would  be  too 
difficult.  All  these  operations  would  require  the  use  of  e 
command- line  format.  The  unary  operations  (MODIFICATION, 
DELETION,  PROJECTION,  end  SELECTION)  must  be  used  with  a 
obms  table  already  In  reference.  The  other  binary  operations 
win  neve  to  specify  the  DBMS  tables  Involved  as  pert  of 
their  command-line  format. 

M 


(2)  Arithmetic 


In  support  of  conditional  statoatnts  and 
duary  processing  tha  DBMS  will  hava  to  include  a  basic 
arithnatle  capability.  The  following  operations  are  needed i 
Addition.  Subtraction.  Multiplication.  Division,  equals, 
Greater-Then,  Less-Than,  Greater-Than-Or-Enual-To,  and 
Less-Than-Or-Equal-To.  These  are  not  intended  as  stand 
alone  operations,  but  are  necessary  to  the  successful 
performance  of  other  operations. 

(3)  Aggregate 

In  support  of  conditional  statements  and 
query  processing  the  DBMS  will  have  to  have  a  basic 
aggregate  function  set.  The  following  functions  need  to  be 
included:  Total,  Count,  Max,  Min,  and  Average.  These  are 
not  intended  as  stand  alone  operations,  but  are  necessary  to 
the  successful  performance  of  other  operations. 


In  support  of  user  defined  questions  across 
multiple  DBMS  tables,  there  must  be  a  capability  similar  to 
the  "Mind”  command,  only  not  limited  to  a  single  table.  The 
result  of  a  query  would  be  a  new  table  containing  the 
desired  information,  but  no  change  would  have  been  made  to 
the  tables  that  provided  the  information.  A  eownend-llne 
format  would  be  required  for  this  operation. 


d.  DBMS  Commands 

Ct)  Find 

Used  to  bring  a  tuple,  free  the  single 
teble  in  reference,  thet  eeets  e  specified  condition  onto 
the  screen  by  scrolling.  Additionally,  the  user  is  notified 
If  enother  tuple  meets  the  sene  condition.  This  ooeretlon 
will  reaulre  the  use  of  e  eommand-llne  forest. 

(2)  insert 

New  tuples  ere  edded  to  e  teble  by  editing 
"blank"  tuples.  Blank  tuples  ere  eutonetleelly  found  et  the 
end  of  the  teble,  or  ere  crested  by  using  the  "odd"  commend 
to  Insert  them  ebove,  or  below,  the  present  eursor  position. 
TMs  ooeretlon  is  performed  in  en  on-screen  fornet. 

(3)  Delete 

By  using  the  UIM  editor  feetures  e  single 
tuple  cen  be  deleted,  m  en  on-sereen  forest.  However,  for 
multiple  tuple  deletions  e  command-line  format  would  be 
required, 

C4)  Add 

as  an  aid  to  the  user,  the  add  command  will 
place  a  "blank”  tuple  either  above  or  below  the  tuple 
referenced  by  the  cursor.  This  operation  is  performed  in  an 
on-screen  format.  Xf  no  entries  are  made  in  the  blank 
tuple,  it  is  ignored  by  the  DBMS  application. 


(5)  Output 

Used  to  send  the  content*  of  a  table#  or 
tablet,  to  some  designated  output  device.  The  output  format 
always  defaults  to  the  "table”  display.  if  aore 
sophisticated  output  foraets  are  desired  then  e  Fora 
Generator  table  een  be  specified  to  control  the  output. 

3.  1*88  Spread-Sheet 

The  soread-sheet  application  is  a  fairly  well 
defined  and  conceptually  simple  program.  Its  functions  are 
well  defined  and  It  Is  not  expected  to  react  to  unexpected 
demands. 

a.  spread-sheet  Display  Forest 

soread-sheet  hes  a  single  display  format  and  it 
Is  caned  "table".  Figure  a. 5  Ulustretes  the  "table" 
display.  Only  the  value  of  each  entry  position  is 
displayed,  not  its  functional  content.  The  spread-sheet 
"table"  dlspley  does  not  have  a  direct  correspondence  to  the 
spread-sheet  data  table  described  In  Chapter  1,  section  CC) 
since  there  is  no  need  for  the  user  to  be  concerned  with  how 
the  application  program  must  use  it. 

b,  Spread-Sheet  Editing 

The  spread-sheet  metes  use  of  the  tfiw  described 
In  Section  (A),  above.  However,  this  application  mates  use 
of  two  cursors  which  are  related  to  each  other.  The 
"bccitien”  carter  is  the  lower  one,  and  It  moves  across  the 
celusns  and  rows  of  the  "table"  display.  Its  function  is  to 


indicate  whleh  entry  position  la  currently  belno  referenced 


by  the  epp licet Ion. 
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Floura  6.5  -  "Table"  Display  Format  for  Spread-Sheet. 


The  UIM  cursor  motion  commands  control  the  "position"  cursor 
and  allow  it  to  roam  over  the  entire  spread  sheet.  The 
"command"  cursor  is  always  in  the  command  line  area  of  the 
screen ,  and  is  used  to  write  into  the  entry  position  marked 
by  the  "position"  cursor.  Xt  is  on  the  commend  line  that 
the  functional  contents  of  the  referenced  entry  position  are 
displayed. 

c,  Spread-Sheet  Functions 
(l)  Arl thistle 

since  the  Spread-Sheet  Is  a  numerical 
mode lino  tael  It  will  need  a  substantial  arithmetic 
capability.  The  fellewino  operations  are  needed!  Addition. 


Subtraction,  Multiplication,  Division,  Exponentiation, 
Absoluts  value.  Truncation,  ftoundlnq,  Logarithms,  and 
Trigonometric  Functions,  Thasa  operations  east  be  capable 
of  stand  alone  operations  slaliar  to  those  In  a  calculator, 
and  be  capable  of  inclusion  in  other  operations  and 
conditions. 

(2)  Aggregate 

since  the  Spreadsheet  Is  a  numerical 
modeling  tool  It  will  need  a  substantial  aggregate  modeling 
capability.  The  following  operations  are  needed!  Total, 
Count,  maximum.  Minimum,  Average,  and  Net-Present-Value. 
These  operations  will  not  have  a  stand  alone  capability 
since  they  are  intended  for  inclusion  In  other  operations, 
d,  Soread-Sheet  Commands 

(11  Find 

Used  to  find  those  entry  positions.  In  the 
referenced  spreadsheet,  that  meet  some  specified  condition. 
The  eursor  will  be  placed  on  the  first  such  entry  position 
and  a  prompt  generated  to  shoe  If  there  Is  another.  This 
operation  will  require  the  use  of  a  command- line  format, 

<21  lam* 

Used  to  place  the  contents  of  another 
spreadsheet  alongside  the  current  spread-sheet  at  the 
indicated  edge.  This  operation  vlll  require  the  use  of  a 


command- line  format. 


(3)  Wove 


Used  to  chanqe  tha  current  position  of  on 
ontlro  row  or  eoluon  on  tho  spread-sheet.  This  oporstlon 
will  rooalro  tho  oso  of  s  command-line  format. 

(4)  Ptlote 

In  reference  to  a  spoelfle  entry  position* 
It  sets  tho  value  to  null.  For  rows  or  eoluans  It  totally 
removes  them  and  moves  the  surrounding  rows  and  columns  to 
fill  the  OOP,  This  operation  will  require  the  use  of  o 
command-line  format, 

(5)  Copy 

used  to  duplicate  a  row*  column*  or 
specific  entry  position  at  another  referenced  location.  This 
operation  will  require  the  use  of  a  command-line  format. 

(6)  Add 

Used  to  place  a  blank  row  or  eolumn  in  a 
location  referenced  by  the  present  cursor  position.  This 
operation  will  require  the  use  of  a  command-line  format. 

(7)  Output 

Used  to  send  the  contents  of  the  spread¬ 
sheet  to  some  indicated  output  device.  The  user  can  Indicate 
whether  to  send  the  spread-sheet  display*  vhleh  only 
contains  the  entry  position  values*  or  the  contents  of  the 
actual  spread-sheet  table*  which  contains  both  the  value  and 
the  function*  to  the  output  device.  Subaarts  of  the  whole 
soread-sheet  may  be  indicated  for  output, 
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The  Porn  Generator  will  be  en  lnportent  pert  of  the 
IASS  since  it  is  reasonable  to  expeet  other  applications, 
the  dsns  for  exaapla,  to  make  use  of  it  to  support  their 
operations.  It  also  has  two  inodes  of  operation.  "Design" 
tine  is  when  the  new  form  is  prepared  by  the  user  and  ell  of 
its  parts,  called  "blocks",  ere  oositloned  end  Identified  as 
to  their  function.  "Use"  tine  is  when  the  oreviously 
designed  form  is  called  on  to  output  the  specified 
Information  in  the  prescribed  format. 

a.  Form  Display  Format 

There  is  one  available  display  format  for  the 
Form  Generator,  called  "oaqe",  and  it  is  shown  in  Figure 
6.6.  This  disolays  the  form  in  the  actual  format  for  use- 
time.  The  prompts  for  each  block  are  shown  as  well  as  their 
associated  entry  positions.  The  "function"  and  "i/o"  values 
of  each  block  appear  on  the  command  line  when  the  block  is 
referenced  by  the  cursor. 

b.  Form  Editing 

In  "page"  format  the  user  begins  with  a  blank 
sereen  and  is  free  to  move  the  eursor  to  any  position  and 
make  entries.  Form  editing  is  a  mueh  more  formal  procedure 
then  in  any  of  the  other  applications.  Entries  must  consist 
of  e  set  number  of  parts  to  be  accepted  by  the  system. 
First,  a  prompt  of  sero  or  mere  characters,  whleh  will 


appear  on  the  display. 


Flour*  6.6  -  "Pace"  format  for  Form  Ganarator. 


Seeond,  the  number  of  spaeas  reserved  on  th*  form  for  tha 
entry,  which  will  alao  appear  on  th*  display.  Third,  « 
symbol  lndleatlnq  how  this  entrv  win  be  used  by  the  form 
aenerator  (Input,  output,  eall  to  text  file,  etc.).  Fourth, 
the  query  statement  uoon  which  tha  output  Is  based,  tha 
table  and  field  name  where  tha  input  Is  to  stored,  or  tha 
name  of  tha  text  file  to  be  output. 

Extensive  us*  is  made  of  tha  command  line  while 
fllllnq  In  each  block,  only  th*  first  two  parts  of  a  block 
entry  are  shown  on  the  actual  form.  Th*  other  two  parts  are 
dismayed  in  the  command  line  area  when  the  block  Is 
referenced. 

As  In  previous  applications  the  actual  ehanpes 
made  durlnc  editing  are  not  effective  until  the  user  issues 
a  "save”  command. 

10A 


e.  Form  Functions 

(1)  Arithmetic 

sine*  the  Porn  Generator  ean  make  usa  of 
DBMS  queries  and  condition  statements  in  acquiring  the 
information  to  complete  a  block.  It  is  necessary  to  provide 
basic  arithmetic  support.  The  following  operations  should  be 
included?  Addition,  Subtraction,  Multiplication,  and 
Division.  These  are  not  intended  as  stand  alone  operations, 
but  for  inclusion  in  other  ooeratlons. 

(2)  Aggregate 

As  the  Form  Generator  can  make  use  of  DBMS 
queries  and  condition  statements  in  acquiring  the 
information  to  complete  a  block,  it  is  necessary  to  provide 
some  aggregate  function  suooort.  The  following  functions 
should  be  included:  Total,  Count,  Maximum,  Minimum,  and 
Average.  These  are  not  Intended  as  stand  alone  operations, 
out  tor  inclusion  in  other  operations. 

(3)  Usage  Indicators 

Slnee  the  form  and  its  blocks  must  be 
capable  of  supporting  a  wide  range  of  uses,  each  form  is 
tailor  made  by  the  user.  The  purpose  of  each  block  must  be 
indicated  by  the  "l/o"  field  in  a  manner  that  shows  how  the 
"function”  block  will  be  treated  at  "use"  time.  For 
example:  The  function  field  of  an  input-block  might  tell 
where  the  item  is  to  be  stored.  For  an  output-block  it  may 
specify  the  databese  table  and  the  query  operation  on  it. 
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necessary  to  qet  the  item,  Tor  •  text-block  It  may  specify 
the  text  file  that  will  be  inserted  in  the  fern  et  that 
location. 

d.  Porn  Connands 

(1)  rind 

used  to  find  a  bloc*  objeet  that  neats  a 
specified  condition  by  movinq  the  cursor  to  its  start.  The 
user  is  notified  if  there  are  any  more  blocks  that  meet  the 
condition.  This  operation  requires  the  use  of  a  command- 
line  format. 

(2)  Insert 

nee  blocks  are  Inserted  by  edltlnq  the 
blank  area  of  a  line  in  the  proper  manner  as  described  In 
Subsection  (bl  above.  This  is  done  in  an  on-screen  format. 
Other  forms  may  be  inserted  into  the  oresent  form  at  a 
eomoieteiy  blank  line,  but  requires  the  use  of  a  command- 
line  format, 

(3)  Hove 

Used  to  move  a  display  line(s),  and  the 
blocks  on  it,  to  a  new  position  on  the  form.  This  operation 
requires  the  use  of  a  eommand-iine  format. 

(4)  Delete 

Used  in  reference  to  bloeks,  it  eliminates 
the  block  and  leaves  the  space  on  the  line  blank.  In 
reference  to  lines,  it  eliminates  ell  blocks  on  the  line, 
removes  the  blank  line,  and  all  lover  lines  move  up.  This 
operation  is  performed  in  an  on-scraen  format. 
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(5)  Copy 

Usod  to  duplicate  a  Una,  or  Unas,  on  tha 
for*  Put  In  a  different  location.  This  operation  Is 
perforaed  In  a  command-line  format. 

(6)  Add 

Adds  a  blank  line,  above  or  below  the  line 
referenced  by  the  cursor.  This  operation  is  performed  in  an 
on-screen  format. 

(75  Output 

used  to  send  the  contents  of  the  for*  table 
to  an  indicated  output  devlee.  The  user  ean  send  the 
displayed  version,  as  shown  in  Figure  6.6,  or  can  oot  to 
output  the  entire  form  table  in  tabular  format  so  as  to  see 
all  the  Information  associated  with  each  bioek, 

s.  i&flg.  ms*misL«&n 

The  Electronic  ball  packaae  suoports  the  user  In 
sending  messaoes  to  other  users,  for  reading  at  a  later 
time.  Upon  entry  to  the  IASS  the  user  will  be  prompted  If 
there  Is  mall  In  the  mailbox.  Bv  entering  the  wall  package 
the  user  will  be  greeted  by  a  one  line  display  synopsis  of 
each  message,  whleh  eannot  be  edited.  The  standard  mall 
display  format  will  be  entered  and  the  user  will  be  tree  to 
reed,  edit,  and/or  delate  current  massages  as  well  as 
ceepose  new  ones.  Each  message  has  a  unique  TO  number  and 
the  user  ean  refer  to  messages  by  the  ID,  originator. 
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subject,  or  tlae*stamp.  Outgoing  messages  or*  actually  sent 
whan  tho  uaor  leaves  tha  Mall  application*  by  removing  all 
messages  In  the  usor  mailbox  that  art  not  addressed  to  tha 


user  and  routing  them  to  their  proper  destination, 
a.  Mall  Display  Format 

There  is  one  display  format  available  for  Mall* 
and  it  Is  called  "page"  format.  Figure  6.7  is  an 
Illustration  of  "pace"  format.  Each  messaoe  Is  displayed  on 
the  sereen  with  Its  fields  organized  In  a  vertical 
direction.  Each  field  has  an  associated  entry  position  that 
is  deslanated  by  delimiters. 


(user  entered  command)  R«f  CM  Mailbox 


(prompt)  tt»Messages 

From  » „ in ■  in .  ■- -  — t - -  ■  - ii--*  ID t  •« 

To  t-t — i - »  — i 

Subl  mr— r - »  TlneinMMIi 

»  — — - ~|T - 

as  •* 

i  - -  i 


Figure  6.7  -  "Pago"  format  for  Electronic  Mall. 

b.  Mall  Editing 

The  Mall  paexage  maxes  use  of  the  standard  UIM 
described  In  Section  (A) *  above.  The  user  may  perform  the 
standard  editing  functions  on  actual  messages  or  on  message 
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"blanks".  Zn  "mage"  styla  display  tha  osar  moves  between 
mas sagas  by  using  tha  "seroll"  command.  On  aaeh  message  tha 
asar  aay  perform  editing  oparatlens  In  any  of  tha  antry 
positions.  Movement  batvaan  antry  positions  Is  posslbla  only 
bv  using  cursor  notion  kayo. 

Outgoing  messages  ara  eraatad  by  adltlng  ona  of 
tha  massaga  "blanks"  at  tha  and  of  tha  table.  or  by  using 
tha  "add"  command  to  insert  a  "blank"  massaga  after  the 
currant  ona  and  than  editing  this  "blank”.  Additionally, 
editing  tha  contents  of  the  "To"  field  in  a  currant  massaga. 
so  that  It  no  longer  corresponds  to  tha  present  user,  turns 
the  massaga  into  an  outgoing  ona. 

All  editing  changes  ara  not  actually  imolamantad 
until  tha  user  issues  a  "save"  command.  Outgoing  massages 
ara  sent  whan  tha  user  issues  a  "oult"  command  to  leave  the 
mall  package.  At  that  time  tha  system  finds  all  massages 
that  ara  not  addressed  to  tha  currant  t»er.  updates  tha 
tlne*eteno  on  than,  and  than  sands  than  to  tha  appropriate 
user,  since  users  often  have  collective  names,  such  as 
"oversight  committee”,  that  include  more  than  ona  user, 
there  is  a  special  eharaetar  tacked  on  to  tha  standard 
destination  address  to  indicate  that  tha  aassaga  is  to  tha 
other  users  in  that  collective  address. 


ill 


e,  Nail  Function* 

<t)  Multi-Hat  Name  Designator 

a  spaelal  enaractar  that  is  plaead  in  front 
of  a  nano  that  corresponds  to  more  than  ona  user  name.  Tha 
atilt! -hat  naa*  actually  refers  to  a  database  table  that 
contains  the  names  of  the  users  who  constitute  the  muitl-hat 
name.  At  use  time/  the  system  will  strip  the  multi-hat  name 
from  the  message,  make  the  proper  number  of  copies  of  the 
message,  insert  the  orooer  user  names,  and  send  the 
messages. 

d.  Mall  Commands 

(1)  Find 

Used  to  move  the  display  to  the  message 
that  meets  a  certain  condition  (e.g.  From  *  'Boss',  Tim-  < 
'1  Nov',  SubJ  «  'Schedules').  Additionally,  the  user  Is 
notified  If  there  are  more  messages  that  meet  the  condition. 

(2)  Delete 

Deletes  the  message  being  referred  to  by 
the  cursor.  To  delete  multiple  messages  It  ean  be  used  In  a 
command  line  with  a  condition  statement. 

O)  Copy 

Qlven  a  message  object  It  mill  duplicate 
the  object  and  insert  it  into  the  mailbox. 

(4)  Add 

Places  a  blank  message  above,  or  below,  the 


message  being  displayed. 


In  concluding  Chapter  *  It  la  Important  to  eaphaslze 
that  the  Old  It  a  vary  lapleaentatlon  dependant  part  of  the 
I Ada,  Chat  thla  chapter  attaapted  to  deaonatrate  vaa  that 
the  coaaand  eategorlet  defined  In  Chapter  2  could  be 
iepleeented  by  a  eoaeon,  yet  slapllfled,  user  interface  by 
using  a  seall  eoaaand  vocabulary  coupled  elth  a  eoaeon 
display  and  editing  foraat.  This  Is  not  the  only  way  to 
present  the  user  Interface*  only  a  suggestion. 


VII.  CONCLUSION 

The  preceding  six  chapter  have  attempted  to  lay  the 
groundwork  for  the  poaslble  design  and  implenentatlon  of 
what  has  been  called  an  Integrated  Application  Software 
System  (TASS).  This  thesis  Is  the  first  small  steo  toward 
the  study  of  such  a  system,  and  the  majority  of  the  work 
remains  to  be  done. 

This  thesis  approached  the  topic  from  a  broad 
perspective  and  did  not  saek  to  get  down  to  speeifle 
Implementation  Issues.  Instead  Chapter  2  reviewed  the 
apparent  characteristics  of  five  application  programs,  and 
the  aependlces  provided  more  detail  on  each.  Chanter  3  took 
the  characteristics  of  the  logical  file  tyoe  associated  with 
each  application  and  formed  them  into  a  common  data  object. 
Chapter  4  took  the  common  data  object  and  explained  a  set  of 
operations  on  it.  Chapter  3  described  how  each  of  the 
included  applications  might  interface  to  the  common  data 
objeet  by  using  the  operations  of  Chapter  4.  Lastly,  Chapter 
•  attempted  to  Illustrate  how  the  user  would  interact  with 
the  applications  in  the  I ass  through  a  eommon  interface. 

One  point  oust  bo  emphasised  and  it  is  that  an  IASS  is 
not  a  relational  Database  Management  System  (DBMS).  There 
are  enough  dims  applications  already  proven  and  available  on 
the  market.  See  Appendices  (C)  and  (P)  for  two  examples. 


114 


What  th«  I ASS  does  la  try  to  usa  tha  OSMS  approach  to 
invisibly  support  tha  user's  effort  to  utilise  tha  various 
and  unloua  applications.  Tha  XA88  conceptual  level  is  a 
common  bond  between  all  included  apolleatlons  and  while  it 
is  the  heart  of  the  systea.  it  should  be  wept  hidden  froa 
the  user,  except  in  specialized  applications  llwe  the  DBMS, 

If  the  user  is  always  given  direct  access  to  the 
conceptual  level  and  its  operations,  then  the  IASS  is 
nothing  more  than  a  DBMS.  In  fact,  such  a  capability  is 
already  present  in  the  DBASE  II  system.  Appendix  (E). 
although  it  would  be  qreatly  improved  by  incorporating  some 
of  the  better  presentation  ideas  from  the  SEOUITUR  system. 
Appendix  (r). 

It  must  be  emphasized  that  this  thesis  is  a  limited,  and 
very  subjective,  view  of  the  IASS.  Prom  the  study  of  this 
hypothetical  IASS  it  seems  clear  that  such  a  system  could  be 
implemented.  However,  no  soeeifle  estimation  can  be  made  on 
the  effectiveness  or  efficiency  of  such  a  system.  It  would 
be  reasonable  to  expect  the  efficiency  to  be  less  than  that 
of  the  individual  application  paewages,  but  there  is  no  way 
of  determining  how  much  less.  These  are  very  lmoortant 
eonelderatlons  and  will  have  to  be  studied  before  the  true 
usefulness  of  an  IASS  can  be  estimated. 

Much  effort  was  placed  on  the  conceptual  level  of  the 
IASS,  and  yet  it  seem  certain  that  the  user  Interface  will 
be  the  portion  of  the  IASS  that  will  determine  its  success 
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or  folloro  ••  on  actual  system.  It  la  important  to  daflna 
the  ultimata  ooals  of  an  XAS8  in  raallatle  tarna  ao  that  an 
measurable  objaetlva  exists.  After  aoma  atudy  thara  apoear 
to  ba  two  Important  ooala  In  tha  XAS8  daalon. 

Tha  flrat  la  to  raduea  tha  coat  of  owning  tha  aaoarata 
application  proorama  by  combining  than  Into  ona  IASS.  Since 
It  haa  baan  shown  that  tha  five  glvan  applications  hava  much 
in  common  that  can  ba  factored  out  and  placed  In  a  common 
conceptual  level*  It  would  apeear  reasonable  to  expeet  tha 
same  from  any  future  aoplleations  accepted  for  inclusion. 
TMs  common  conceptual  level  reduces  the  amount  of 
duplication  necessary  to  "own"  tha  Individual  aoplleations. 
Economic  aavlnos  would  hopefully  be  realized  from  the 
smaller  amount  of  code  needed*  its  more  uniform  structure* 
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and  the  sharing  of  capabilities  between  aooilcatlons.  The 
design  of  tha  conceptual  level  and  the  Individual 
application  packages  will  hava  tha  major  effeet  on  achlevlna 
this  goal. 

The  second  goal  la  that  tha  user  must  pereelve  an 
improvement  In  using  tha  XA8S  over  using  the  separata 
applications.  Tha  XA88  must  ba  more  "user  friendly11  than 
the  disjoint  application  programs  it  replaces.  Simplicity 
and  capability  must  ba  emphasized  over  system 
sophistication.  Each  capability  that  will  be  incorporated 
in  an  application  must  be  measured  as  to  its  complexity  and 
usefulness.  It  is  not  justifiable  to  Increase  system 


complexity  just  to  add  a  fancy  but  little  uaad  feature.  Thu 
design  of  tha  user  Interface  aodula  and  tha  individual 
application  paeXaaes  will  hava  tha  major  affaet  on  aehlavino 
this  goal. 

Xt  would  appear  to  ba  too  aariy  to  attamot  tha 
implawantatlon  of  sueh  a  systam.  Instead*  more  investigation 
needs  to  ba  dona  and  tha  objectives  more  tightlv  defined. 


APPENDIX  A I  WORD  STAR 


WORD  STAR  it  a  word  processing  program  davtlopad  by 
miero-Pro  to  combine  tha  eapabilltlaa  of  a  sertan  editor  and 
an  on-screen  text  formatter.  The  result  is  a  very  powerful 
text  editor  whleh  displays  the  referenced  file  as  it  will 
appear  on  the  printed  page. 

word  STAR  is  primarily  menu-driven.  The  commands  whleh 
are  presently  valid  are  displayed  In  a  menu,  and  are 
executed  by  Keystroke  combinations.  On-line  Information  Is 
available  to  the  user  concerning  many  other  aspects  of  word 
STAR.  The  menu  driven  feature  eases  user  initiation  to  word 
star  and  is  part  of  the  Help  facility.  The  level  of  help  Is 
selectable  to  match  the  users  level  of  experience,  and 
determines  the  extent  to  whleh  the  menus  are  displayed  on 
the  CRT. 

WORD  STAR  is  composed  of  a  set  of  seven  hierarchically 
orpanlzed  menus  or  environments,  as  shown  in  Table  A.i.  The 
user  enters  WORD  STAR  In  the  No-rile  environment.  At  this 
point  there  is  no  file  m  reference,  the  object  granularity 
is  the  file,  and  the  menu  options  Include  commands  tot 
change  the  logged  disk  drive,  set  the  automatic  directory 
display  feature  (on/off),  set  the  help  level,  print  a  file, 
rename  a  file,  eopy  a  file,  delete  a  file,  run  a  program, 
open  a  document  file,  and  open  a  non-document  file. 


Table  A, 1  •  WORD  STAR  Nana  Hierarchy, 
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LEVEL 

MENU 

1 

.  NO 

flla 

2 

Rain  Mono 

a 

a. 

Help 

b. 

On-screen  Format 

e. 

Print  Control 

d. 

Quleie  Edit 

a. 

Flle/Bloek 

WORD  STAR  reeounlzes  two  types  of  flies,  "document"  and 
•non-doeument".  A  document  flia  can  either  ba  a  taxt  flla 
processed  by  a  word  orocessor  or  a  program  run  by  a 
computer.  A  non-doeuwent  file  is  a  special  puroosa  flla 
whien  la  uaad  by  anotnar  aoftwara  product,  and  will  not  ba 
dlacuaaad  further. 

The  on-screen  adltor  and  fornattar  ara  Invoked  by 
seiectmo  tna  aanu  option  to  opan  a  document  flla,  Thla 
eauaas  word  star  to  antar  tna  Main  Nana  anvlronmant  with  a 
•Pacific  flla  in  reference,  If  tha  flla  pravloualy  existed 
it  is  made  currant,  otherwise  a  naw  flla  la  craatad  and  made 
currant.  On  antarlna  tha  Main  Nana  environment,  a  status 
llna  and  a  rala  ara  initialised.  Tha  status  llna  contains 
information  about  tha  systau  •  tha  naaa  of  tha  flla,  tha 
papa  within  tha  flla,  tha  coloan  and  row  nuabor  tha  cursor 
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is  at,  and  the  insertion  mode  ton/off).  Th#  rula  lndicatas 
tha  right  and  left  nargin  position  as  wall  as  tha  tab 
positions.  Tha  Main  Menu  raprasants  tha  basic  flla  adltlng 
environment  whara  tha  usar  will  ranaln  until  It  Is  daeldad 
to  quit  tha  currant  flla  and  raturn  to  tha  No  Flla  Menu  or 
tha  operating  system,  Zn  any  ease,  word  star  does  not 
permit  lateral  movement  between  tha  sub-menus  of  tha  Main 
Menu. 

A  useful  feature  word  STAR  employs  is  "word  wrap”,  with 
word  wrap,  the  usar  does  not  have  to  insert  earrlaoa  returns 
at  the  end  of  each  line.  As  the  text  overruns  the  end  of 
the  line,  WORO  STAR  automatically  starts  the  next  line.  Zn 
this  wav,  tha  usar  merely  Inputs  an  entire  block  of  text  as 
a  continuous  ASCII  character  string,  and  leaves  the 
fermattlno  to  the  system,  in  the  Main  Menu,  the  user  can 
adit  the  flla  In  granularities  of  character,  word,  and  Una, 
Insertion  Is  a  "togoied"  operation  (on/off),  where  the  usar 
Is  either  In  Insert  mode  or  overwrite  mode.  Any  keystroke 
entered  Is  either  Inserted  in  the  text  at  the  cursor 
position,  shifting  characters  to  the  right  to  accommodate 
It,  or  overwrites  the  character  at  the  cursor  position.  To 
facilitate  on-screen  editing,  the  wain  Menu  contains 
eoamands  to  control  cursor  movement  and  to  seroll  the 
screen.  It  is  possible  to  Insert  tabs  or  end-of-peracraph 
markers.  There  is  a  "Find  and  Replace11  commend  whleh  can  be 
repeated  any  number  of  tines.  Deletions  ean  be  done  on  e 
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single  character,  a  word,  or  an  entire  line.  The  Main  Menu 
also  contains  options  to  seleet  one  of  the  five  submenus. 

The  Quick  Editing  environment  supports  editing  on  higher 
levels  of  abstraction  of  text  objects  than  the  Main  Menu, 
There  are  additional  eursor  movement  commands  to  give  a 
wider  range  of  control  and  granularity.  As  In  the  Main  Menu 
environment,  the  user  can  scroll  the  display,  but  now  it  is 
continuous  at  nine  user  selectable  rates  until  stooped  by 
command.  Insertions  are  accomplished  in  the  same  way  as  in 
the  Main  Menu  environment,  but  deletions  are  possible  on  a 
wider  range  of  objects.  There  is  a  feature  to  allow  a 
command  to  be  repeated  at  one  of  nine  user  selectable  rates, 
until  stopped  by  command. 

The  Block  environment  provides  the  user  a  set  of 
operations  on  a  block  of  text.  WORD  star  considers  an 
entire  file  to  be  a  special  ease  of  a  block  of  text.  Piles 
cen  be  saved  by  several  menu  options t  save  and  resume  the 
referenced  file,  save  and  gult  to  the  operating  system,  save 
and  exit  the  referenced  file,  and  copy  to  another  file. 
Piles  may  also  be  renamed,  deleted,  printed,  or  cult  without 
saving  changes.  To  support  these  file  operations,  the  Block 
Menu  contains  options  to  change  the  logged  disk,  and  to  turn 
the  automatic  directory  listing  on  or  off.  In  this 
capacity,  the  Block  environment  is  used  as  a  successor  to 
the  Main  or  Quick  Editing  environments  after  the  cursor  Is 
positioned.  Blocks  In  a  file  must  be  marked  by  the  user. 
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A*  a  delimited  aggregation  of  text,  a  block  can  ba  moved 
within  the  same  file.  Copying  blocks  of  text  can  either  be 
within  the  referenced  file  or  between  the  referenced  file 
and  an  external  file,  Bloek  copying  between  filet  are  bi¬ 
directional,  Copying  a  bloek  to  an  external  file  entails 
overwriting  an  existing  file  or  creating  a  new  file. 
Cooylng  a  bloek  from  an  external  file  entails  moving  the 
entire  external  file  to  the  point  in  the  text  indicated  by 
the  cursor.  Any  marked  bloek  can  also  be  deleted.  As  a 
precautionary  measure,  word  star  allows  the  user  to  hide 
block  markers,  and  only  blocks  which  are  visibly  marked  can 
be  deleted.  In  addition  to  a  text  block  being  organized 
into  a  continuous,  unstructured  string  of  text,  word  STAR 
supoorts  a  columnar  organization. 

The  previously  described  menus  contain  operations  to 
create,  edit,  position  the  cursor,  or  output  a  text  file. 
The  format  of  the  file,  either  as  it  is  visually  displayed 
or  printed  out,  is  defined  by  a  set  of  formatting  parameters 
associated  with  the  file  or  by  commands  embedded  in  the 
file.  The  formatting  parameters  associated  with  a  file  are 
initially  set  to  default  values  and  the  set  of  embedded 
commands  is  initially  empty. 

Formatting  in  WORD  STAR  is  primarily  done  on-sereen  with 
the  options  contained  in  the  0n-8ereen  Menu.  The  on-screen 
formatting  commands  are  those  whose  effects  can  be  visually 
displayed,  and  they  are  listed  in  Table  A. 2, 
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Table  A. 2  -  WORD  STAR  On-Screen  Formatting  Command!, 


.  Sat  la£t  margin 

•  Set  right  margin 

•  Release  marolns 

•  set  and  elear  tabs 
,  Indant  a  paragraph 

.  Create  a  spaelai  rule 

•  Canter  text 

.  Set  line  spacing 


The  on-Sereen  Menu  also  contains  options  In  the  form  of 
(On/Off)  togqles  to  controls  word  wrao,  rule  display, 
variable  tabbing,  hyphenation  halP,  right  margin 
lustlf leatlon,  soft  hyohan,  print  embedded  control 
characters,  and  page  break  display.  If  an  on-sereen 
formatting  ooeratlon  needs  to  be  applied  to  the  previous 
contents  of  the  fll$,  the  applicable  portion  of  the  file 
must  be  reformatted.  Furthermore,  these  formatting 
parameters  are  only  temporarily  aopiied  when  the  file  Is 
referenced.  Any  subsequent  reference  to  a  file  requires 
that  the  on-sereen  formatting  parameters  be  reset. 

homo  STAR  combines  Into  one  menu,  the  Print  Menu,  all 
options  which  ereate  spaelai  printing  effects  not  normally 
dlspiayabie  on  a  video  sereen.  There  are  options  tos  bold 
fees,  double  strike,  underline,  strike  out,  subscript,  and 
superscript.  Since  the  effects  of  these  options  cannot  be 
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display'd  on  tha  vldao  screen,  a  spaelal  character  is  usad 
to  mark  tha  effected  area.  Additional  spaelal  printing 
effects  ara  salaetabla  throuoh  this  menu  on  a  ona  time 
basis t  ovarorlnt  a  character,  indicate  a  non-break  space, 
and  ovarorlnt  a  llna.  Tha  Print  Menu  also  contains  options 
which  control  the  printer  daring  output.  The  user  may  embed 
commands  in  tha  text  flit  to  eause  tha  printer  to  ehange 
pitch,  or  cause  a  pause  to  allow  the  user  to  ehange  the 
print  element  or  ribbon. 

Printing  can  also  be  directed  through  the  use  of 
embedded  dot  commands.  These  commands  are  placed  in  the 
text  file  and  appear  as  regular  text  on  the  display,  but  are 
not  output  to  a  printer  and  forea  wood  star  to  change  a 
printing  parameter  at  print  time.  Dot  commands  alter  the 
default  parameters  WORD  STAR  uses  to  format  the  printed 


page.  Table  A.3  provides  a  listing  of  these  commands. 

Dot-commands  may  be  placed  anywhere  in  the  text,  but 
since  they  are  static  and  tend  to  destroy  the  relationship 
between  what  is  displayed  and  what  is  printed,  they  are 
usually  Placed  at  the  beginning  of  the  text  file.  As  with 
the  options  of  the  Print  Menu,  dot-command  actions  must  be 
supported  by  the  seeelfle  printer  in  use. 

The  last  menu  to  be  described  is  the  Help  Menu.  Help  is 
•on-line"  in  that  it  can  be  Invoked  at  any  tine  through  the 
Main  Menu,  and  is  "dynamic"  in  that  the  level  of  help  ean  be 
adjusted.  The  level  will  determine  how  mueh  information  is 
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displayed  whan  an  option  la  selected.  Tha  Halp  Menu  options 
display  Information  on*  paragraph  reforming,  flags  In  tha 
right-hand  margin*  dot  and  print  commands*  status  llna* 
rular  llna*  how  to  sat  margins  and  tabs*  and  how  to  mova 
blocks  of  tost. 


Table  A, 3  -  WORD  STAR  Dot  Commands. 


1.  Sat  llna  height 

2.  Sat  paga  length 

3.  Sat  too  margin 

4.  Sat  bottom  margin 

5.  Generate  headers 

6.  Generate  footers 

7.  sat  footer  margin 

8.  Reset  oage  number 

4.  Offset  paga  from  left  side  of  printer 

10.  Position  oaoa  number 

11.  Set  character  width 

12.  Porea  a  page  break 

13.  Prevent  a  oage  break 


word  STAR  is  an  axeallant  and  vary  popular  word 
processing  program.  The  sereen-oriented  and  on-line 
formatting  features  are  different  from  other  systems  In  that 
they  are  extremely  easy  to  use.  Onee  experience  Is  gained 
with  woro  STAR  It  Is  difficult  to  use  llne«orlented  editors 
or  off-line  formatting  systems.  The  on-line  help  facility 
makes  WORD  STAR  easy  to  learn  and  user  friendly,  one  aspect 
of  woro  STAR  that  could  be  considered  a  disadvantage  is  the 
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Xarga  eonnand  sat.  Howavar#  baino  aanu-drlvan,  the  coanands 
not  noraaxiy  usad  do  not  hava  to  ba  mssorizad  slnea  tnay  ara 
always  Xlstad  In  tha  aanu. 


APPENDIX  Bl  VI 


"VI"  It  •  text  editor  died  by  the  UNIX  operating  tyaten 
and  was  created  by  the  University  of  California  at  Berkeley, 
and  Bell  Laboratories. 

VI  (visual)  is  a  display  oriented  interactive  text 
editor  with  a  command  vocabulary  size  of  about  ninety  pne. 
The  user  sees  the  CRT  screen  as  a  window  into  the  text  file 
and  all  editing  operations  are  immediately  visible.  Line 
numbers  are  not  displayed  and  have  no  real  use  in  vi, 
although  it  is  possible  to  find  out  the  number  for  a  line. 
For  the  sake  of  protection  the  user  does  not  actually  edit 
the  file,  but  a  cooy  of  it.  At  the  completion  of  a  session 
the  user  will  indicate  whether  to  Keep  the  edited  copy  or 
the  orlqlnal. 

Thera  are  forty  seven  movement  commands  for  control  of 
the  cursor,  whleh  is  the  editor's  point  of  reference,  and 
the  screen  display.  Scope  of  movement  is  possible  over 
file,  screen,  paragraph,  section,  sentence,  line,  word,  and 
character  sized  units.  Up  to  twenty  six  locations  in  the 
file  can  be  merited  for  later  return,  or  specific  locations 
found  that  mateh  a  desired  character  string.  Table  B.i 
lists  the  cursor  movement  commands  available  in  the  VI 
system.  Note  that  there  is  duplication,  in  that  more  than 
one  command  dees  the  same  thing. 
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Tabic  B.l  -  vz  Cursor  Movement  Commands 


1  •  Backward  window 
2.  Forward  window 
3*  Seroll  down  * 

4.  Seroll  up  * 

5.  Backspace  ona  character  * 

6.  Backspace  a  single  character 
?.  Backup  a  word 

4,  Backup  a  word  during  Insert 
4.  Baekuo  to  beginning  of  word 

10.  Retreat  to  previous  line  * 

11.  Retreat  to  beginning  of  sentence 

12.  Retreat  to  beginning  of  previous  paragraph 

13.  Retreat  to  previous  section  boundary 

14.  Linefeed  advance  to  next  line 

15.  Advance  to  first  non-white  space  on  next  line  * 

16.  Advance  to  next  line,  first  white  soaee 

17.  Advance  to  next  line,  sane  column  • 

18.  Advance  to  next  character  * 
is.  Advance  to  beginning  of  word 

20.  Advance  to  end  of  next  word 

21.  Advance  to  section  boundary 

22.  Advance  to  the  next  typed  character 

23.  Advance  to  beginning  of  next  paragraph 

24.  Move  to  previous  line  * 

25.  Move  to  end  of  current  line  * 

26.  Move  to  balancing  parenthesis  or  brace 

27.  Moves  cursor  to  last  line  on  screen  * 

28.  Moves  cursor  to  middle  of  screen  * 

29.  Move  forward  to  beginning  of  word 

30.  wove  forward  to  end  of  word 

31.  Move  to  first  non-white  space  on  current  line 

32.  Move  to  line  number  i  * 

33.  Search  for  word  * 

34.  Search  forward  for  string  ** 

35.  Search  backward  for  string  * 

36.  Search  for  next  mateh  •* 

37.  Repeat  lost  single  character  seareh 

38.  Rind  a  single  character,  backwards  * 

39.  Find  a  single  character,  forward  * 

49.  Reverse  direction  of. previous  find 


*,  s*  Useful  •  see  page  133,  paragraph  (4) 
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Table  B,1  -  (Cent,) 


1 

5 


41,  Find  first  Instance  of  next  character 

42,  Repeat  the  last  sear eh  eeaaand  e 

43,  Hoaes  the  eurser 

44,  Mark  the  present  position  of  the  eurser  * 

45,  Return  to  parked  position  e 

44.  Redraw  the  sereen 

47,  Returns  to  previous  context 

*  Useful  -  see  page  133.  paragraph  (4) 

The  operations  of  Insertion,  modification  and  deletion 
are  supported  by  thirty  commands  that  permit  the  user  a 
varied  level  of  object  control.  Items  that  are  inserted, 
modified  or  deleted  are  Immediately  updated  on  the  sereen  to 
give  the  user  a  current  view  of  the  file  status.  The  user 
also  has  the  ability  to  undo  the  previous  command  it  its 
effects  were  undesired.  Most  Insertion  and  modification 
commands  are  structured  so  that  they  continue  to  operate 
until  the  user  Issues  a  command  to  terminate  them.  Normally 
durlno  insertion  the  user  has  control  of  format  In  that  new 
lines  are  started  by  entering  a  carriage  return.  However 
there  Is  an  option  that  will  let  VZ  determine  when  to  start 
a  new  line,  based  on  line  length,  and  let  the  user  just 
enter  text  as  a  continuous  stream.  Table  R.2  lists  the 
thirty  adit  commands. 

In  order  to  use  vt  the  user  Issues  the  command  "vl" 
followed  by  the  name  of  the  file  to  be  edited.  Zf  this  Is  a 


new  flit,  then  the  ntmt  will  not  bt  found  in  the  directory 
and  VI  will  ertate  on  ttpty  flit.  After  entry,  the  user  will 
issue  eursor  notion  eonnends  to  naneuver  through  the  file, 
and  Issue  edit  contends  to  change  the  contents  of  the  file. 
Thera  are  no  other  nodes  or  displays  available  in  VI. 


Table  B.2  -  VI  Edit  Command  Summary 


1.  Insert  a  number  of  soaees 

2.  Insert  nonorlntable  characters 

3.  Insert  "shlftwidth"  blank  spaces 

4.  Insert  at  the  beginning  of  line 

5.  Insert  at  end  of  line 

6.  Insert  before  the  cursor  ** 

7.  Insert  after  the  eursor  ** 

9.  Insert  new  line  below  current  line 
n.  Insert  new  line  above  current  line 

10.  Insert  text  below  current  line  ** 

11.  Insert  text  above  current  line  ** 

12.  Delete  last  character 

13.  Delete  rest  of  the  text  on  current  line  « 

14.  Delete  character  before  cursor 

15.  Delete  the  following  objeet 

16.  Delete  single  character  under  eursor  ** 

17.  Repeat  last  command  ** 

19.  Join  together  lines  * 

19.  Replace  single  eharaeter  under  cursor 

20.  Replace  characters  at  eursor  ** 

21.  Change  the  entire  line 

22.  Change  single  character 

23.  Change  the  following  object 

24.  Change  rest  of  the  text  on  current  line 
29.  Undo  last  ehanga  to  current  buffer  *« 

2d.  Restore  current  line  to  previous  condition 
27,  Tank  following  object  Into  buffer  * 

2d.  Tank  a  copy  of  current  line  into  buffer 

29.  Repeat  last  text  insertion 

30.  warned  buffer  specification  follows  « 


«,  **  Useful  -  see  page  133,  paragraph  (4) 
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In  addition  to  the  two  command  categories  already  given 
tnara  arc  additional  commands  of  a  miscellaneous  nature# 
Table  B.3  llati  these  additional  commands. 


Table  B,3  -  Miscellaneous  vi  Commands. 


1.  Print  file  status  messaoe 

2.  Clear  and  redraw  the  screen 

3.  Redraw  the  current  "logical*  screen 

4.  suspend  or  restart  output 

5.  Cancel  partially  formed  command 

6.  Return  to  position  in  last  edited  file 

7.  Reformat  lines  in  buffer 

8 .  Indicate  file  and  option  manipulation 

9.  Quit  vi,  enter  line-oriented  editor 


Some  very  basic  formating  commands  for  line  length  and 
indenting  are  direetiy  available.  A  macro  creation 
capability  is  present  to  allow  the  user  to  create 
abbreviations  for  command  strings.  Table  B.4  lists  these 
formatting  commands,  vx  makes  no  claim  to  supporting  a 
formatting  package,  slnee  the  file  will  be  output  In  the 
same  format  the  user  entered  It.  For  special  formatted 
output  e  VI  generated  file  must  be  processed  by  an  off-line 
word  processor,  like  "MROFF  -me*  described  in  Appendix  (0). 

VI  provides  a  high  degree  of  support  to  the  user  for 
restructuring  a  tile,  or  files.  There  are  nine  buffers 


available  tor  storing  deleted  text,  and  twenty  six  buffers 


to  ut«  as  temporary  holding  spacas  while  raordarlng  and 
adltlng.  Tha  text  ean  ba  taken  from  othar  filaa  and/or 
buffers,  for  aaa  In  tha  fiia  currantly  balnq  adltad.  If 
needed,  previously  dalatad  taxt  from  tha  currant  flla  ean  be 
recovered,  and  also  othar  files. 


Table  B,4  -  VI  Formatting  Commands, 


1,  Reformatting  command 

2,  Shift  lines  left  one  "shif twidth" 

3,  Reindent  lines 

4,  shift  lines  right  one  "shiftwidth" 

5,  Prints  current  file  contents 


avi"  is  a  good  screen  oriented  editor  and  has  a  wide 
range  of  capabilities,  however  it  has  some  drawbacks. 

(1)  It  has  a  poorly  designed  user  Interface  slnee  the 
command  vocabulary  is  vary  large  and  the  individual  command 
strings  are  difficult  to  ramambar.  There  does  not  seem  to 
have  been  much  thought  given  to  the  design  of  the  command 
vocabulary, 

(2)  It  takas  a  fairly  long  tlma  to  laarn  tha  VI  system 
and  gain  funetlenal  use.  An  on-line  tutorial  program  Is 
used  to  help  beginners,  since  it  is  hard  to  beeome  familiar 
with  it  on  their  own. 


(3)  VZ  does  not  Inspire  user  confidence  in  that  It  Is 


too  easy  to  accidentally  enter  some  unknown  command  string, 
and  tnere  is  little  correlation  between  what  the  user  wants 
to  do  and  the  eoamand(s)  that  must  be  issued, 

(4)  Proa  personal  use,  about  thirty  three  eoaaands  were 
considered  to  be  generally  useful  (marked  by  *  or  •*),  and 
onlv  ten  of  these  aeeounted  for  the  greeter  majority  of  all 
ooeratlons  (narked  by  **).  The  remaining  vi  commands  were 
generally  treated  as  "window  dressing"  by  all  but  the  most 
sophisticated  users. 

(51  There  is  no  help  facility,  of  any  kind,  provided  by 
the  vi  system.  At  the  very  least,  an  on-line  listing  of 
commands  should  be  provided. 
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APPENDIX  Cl  EDIT 


EOIT  Is  a  text  editor  supported  by  the  UNIX  operating 
system.  EDIT  is  e  simplified  version  of  another  UNIX 
editor  end  contains  a  minimal  set  of  operators.  It  is  line 
oriented  which  means  that  the  main  object  of  EDIT  is  a  line 
of  text  of  some  finite  length. 

EDIT  merely  supports  text  file  creation  and  modification 
operations.  The  user  inputs  text  into  a  file  by  lines, 
indleatlno  the  end  of  a  line  bv  a  earrlaae  return.  A 
display  of  the  file  will  show  an  ordered  list  of  lines  as 
they  exist  in  the  file.  Ordering  of  lines  is  completely 
determined  by  the  system  and  although  the  user  can  use  line 
numbers  as  a  reference,  the  line  number  is  not  directly 
accessible  to  the  user  to  change  or  set.  Any  display  of 
text  by  EDIT  is  done  by  line.  Substrings  can  be  referenced 
within  a  line,  or  lines.  A  formatted  output  display  by  EDIT 
can  only  be  achieved  If  the  user  dlreetly  inputs  the  desired 
format  line  by  line.  No  processing  of  the  contents  of  a 
line  is  done  by  EDIT. 

when  invoiced.  EDIT  sets  aside  a  temporary  eooy  of  the 
referenced  file  in  a  worlelni  buffer.  Tf  the  file  does  not 
already  exist  in  the  directory,  then  it  is  a  new  file  and  is 
created.  The  besle  set  of  commends  available  to  EDIT  are 
listed  in  Table  C.l. 
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Table  C.l  -  EDIT  Command  Summary 


1. 

Edit  a  file 

2 . 

Specify  a  file 

3. 

Append  llne(B) 

4. 

Insert  llne(s) 

5. 

insert  llne(s)  Into 

an 

6. 

Insert  llneCs)  from 

an 

7, 

Delete  llne(s) 

8. 

Copv  line(s) 

9. 

Move  llne(s) 

10, 

Print  JLlne(s) 

11. 

Show  line  number 

12. 

List  llne(s) 

13. 

substitute  a  string 

14. 

Search  for  string 

15. 

Undo  last  command 

16. 

Make  effect  of  command 

17. 

Move  cursor 
-  forward 
•  backward 

18. 

Quit 

axearnal  file 
axtarnal  file 


global 


Searching  for  a  line  haa  the  effect  of  maxing  the  found 
line  the  current  line.  Any  subsequent  editing  operations 
are  done  In  relation  to  the  current  line.  Lines  can  be 
found  and  dlsoiayed  by  line  numbers,  and  ranges  of  lines  can 
be  specified.  Lines  can  also  be  found  and  dlsoiayed  forward 
or  backward,  relative  to  the  current  line,  a  line  can  be 
found  by  any  substring  of  its  contents,  but  the  entire 
substring  must  be  contained  in  one  line.  Because  of  this 
deficiency  a  substring  may  not  be  loeatabla  merely  because 
It  exists  in  the  text  file.  Whan  searching  EDIT  will  move 
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forward  or  backward  and  will  wrap  around  tna  buffer,  so  at 
to  return  to  the  starting  line  If  the  target  objeet  it  not 
found* 

New  lines  ean  be  appended  before  the  current  line,  or 
inserted  after  it*  The  user  Issues  a  command  to  specify  that 
there  are  no  more  lines  to  add.  upon  completion  the  current 
line  is  the  last  line  added.  Additions  can  also  be  made  by 
moving  or  copying  lines  within  the  text  file.  Moving  can  be 
viewed  as  a  combination  of  a  deletion  and  an  Insertion,  ay 
specifying  a  range  of  lines  to  be  changed,  they  are  deleted 
and  the  system  enters  Insert  mode  for  the  user  to  add  the 
new  lines.  Additionally,  Insertions  are  possible  from  other 
text  files. 

Modifying  a  line  is  done  by  substituting  a  new  string 
for  en  already  existing  target  string  on  the  line.  If 
desired,  the  substitution  ean  have  global  effect  in  that  it 
win  modify  all  occurrences  of  the  target  string  on  all 
lines. 

Deletion  is  usually  accomplished  by  indicating  the  line, 
or  lines,  to  be  deleted.  A  search  command  ean  be  used  with 
the  deletion  operetlon  when  the  specific  line  numbers  are 
not  know. 

EDIT  protects  the  user  from  making  inadvertent  changes 
to  a  text  file.  The  effects  of  the  last  executed  command 
that  effected  the  buffer  ean  be  reversed.  Additionally,  the 
effects  of  the  editing  session  do  not  become  permanent 

ill 


units*  the  user  Issues  «  command  to  asks  them  permanent.  At 


that  point  the  edited  copy,  which  is  in  the  buffer,  replaces 
the  original  file  in  the  directory*  Leaving  EDIT  without 
Indicating  to  make  the  changes  pernanent  is  like  the  editing 
session  never  occurred. 

In  addition  to  writing  a  whole  buffer  out  to  the 
directory,  subparts  can  be  written  to  another  text  file. 
This  is  done  by  specifying  the  range  of  lines  and  the  file 
to  be  written  to. 

The  EDIT  text  editor  is  very  basle  which  is  both  an 
advantage  and  a  disadvantage.  It  has  a  minimal  command  set 
and  therefore  is  easy  to  learn.  The  biggest  problem  is  that 
It  is  line-oriented.  As  sueh,  modifications  are  done  a  line 
at  a  time,  where  eaeh  line  is  a  separate  entity.  It  does  not 
treat  the  file  as  a  whole,  but  as  a  disjoint  collection  of 
lines.  It  imposes  the  Idea  of  line  numbers,  which  do  not 
exist  In  the  text  file,  in  order  to  use  the  editor.  There 
are  fewer  high  level  edltlno  operations  available,  as 
compared  to  current  screen-oriented  editors,  and  they  are 
limited  to  operating  on  lines  and  not  the  text  file  as  a 
whole,  while  capable  of  producing  satisfactory  results,  due 
to  its  line  at  a  time  limits,  the  operation  becomes  tedious 
if  the  file  is  large,  and/or  there  are  a  lot  of  small 
changes  whleh  must  be  done.  Given  the  edvanced  features  of 
todays  line-oriented  editors,  EDIT  is  a  very  arehale  and 
frustrating  way  to  ereate  and  modify  a  text  file. 
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APPENDIX  Dt  NROFF  -ME 

"NROFF  •ME"  Is  a  text  processing  facility  for  files  that 
ere  crested  on  the  Unix  operating  system.  It  was  created  by 
the  University  of  California  at  Berkeley,  and  sell 
Laboratories.  "NROFF"  Is  a  orooram  that  aeeepts  an  Input 
file  prepared  by  the  user  and  outeuts  a  formatted  oaoer  to 
the  user's  design.  "-ME"  Is  a  macro  package  that  enhances 
the  capabilities  of  the  "NROFF"  program  by  adding  additional 
formatting  abilities  and  commands.  The  Input  file  consists 
of  the  actual  text  entered  by  the  user,  through  some  editor 
system,  and  a  series  of  embedded  NROFF  -me  commands. 

There  is  a  large  vocabulary  of  "reouests",  which  are 
really  dot-commands  consisting  of  a  period  followed  by  a  two 
letter  string.  The  basic  NROFF  package  suooorts  seventeen 
categories  of  commands,  and  has  a  total  of  eighty  seven 
commands.  The  -me  package  adds  three  categories  and  a  total 
of  sixty  commands  tor  a  grand  total  of  one  hundred  and  forty 
seven  commends.  Table  D.l  lists  the  NROFF  and  -me  command 
categories,  and  the  number  of  commands  In  eaeh. 

NROFF  -me  times  thirteen  predefined  general  variables  and 
twenty  three  predefined  read-only  variables  to  support  Its 
processing  needs.  The  user  Is  provided  with  a  macro 
facility  to  define  new  commends  In  terms  of  the  basic  set  of 
commands  and  operations  on  the  variables.  This  ellows  the 
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f. 


user  to  abbreviate  •  fairly  long  command  ftraaa  into  a 
•India  command. 


Tabla  D. l  -  NROPP  and  -ME  Coanands, 


COMMAND  CATEGORY . 

COMMANDS 

NRQFF  -ME 

1.  Pont  &  Character  size  Control 

7 

9 

2.  Page  Control 

7 

0 

3.  Text  Filling,  Adjusting  &  Centering 

6 

0 

4.  Displays 

0 

22 

5.  Vertical  spacing 

7 

0 

6.  Line  Length  a  Indenting 

3 

0 

v.  Paragraphing 

0 

4 

s.  "acres.  Strings,  Diversions,  &  Traps 

13 

0 

9.  Number  Registers 

3 

0 

10.  Tabs,  Leaders,  &  Fields 

4 

0 

11.  Inoutoutput  Conventions 

9 

0 

12.  Hyphenation 

4 

0 

13.  Titles 

3 

13 

14.  Headings 

0 

6 

15,  Line  Numbering 

7 

0 

16.  Conditional  Input 

8 

0 

17,  Environment  Switching 

1 

0 

19.  standard  Input  insertions 

2 

0 

19.  Inoutoutput  Pile  Switching 

3 

0 

20.  Miscellaneous 

5 

6 

TOTAL 

87 

so" 

NRQPP  -Ml  is  a  good  word  processing  system  and  It  can 
product  iom  complex  formatting  action*.  However,  It  dot* 
suffer  froa  toat  drawbacks. 

(1)  fllnea  the  flit  is  first  ertattd  by  tnt  text  tditor 
and  than  ran  by  NROPP,  tnt  user  has  a  significant  dtlay  in 
datarainlna  If  tha  daslrad  foraat  was  achltvtd. 
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(2)  Xn  addition  to  dapendinq  on  tno  text  editor,  NROFF 
oust  dopond  on  otnor  programs  to  proproeos*  tno  toxt  <11# 
bofor#  nropp  ean  nondl#  it  for  specialized  reouests.  Two 
examples  of  preprocessors  arc  packages  to  handl#  tabla*  and 
eoaplax  eouation  symboloqy,  While  enhancing  MROFF  -MC#s 
capabilities,  thoy  add  more  eatooorlea  and  commands,  and 
lneroas#  th#  amount  of  tin#  necessary  for  the  user  to  see 
the  actual  results  of  commands. 

(1)  The  user  manual  for  the  NROFF  package  Is  not 
presented  in  sufficient  detail  to  completely  understand  the 
effect,  or  use,  of  all  commands.  Xt  appears  that  the  user 
Is  supposed  to  have  a  basle  understanding  of  the  system 
before  reading  the  manuals! 

(4)  The  command  vocabulary  is  fairly  large  and  they  are 
not  easy  to  remember.  Based  on  Personal  use,  only  about 
twenty  percent  of  the  vocabulary  Is  generally  useful  and 
therefore  remembered.  Table  0.2  presents  a  simplified 
listing  of  the  most  used  commands. 
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Table 


0,2  -  Bade  Commands  NROFF  -me 


1 ,  Page  length 

2,  Lina  spacing 

3,  Lina  length 

4,  Paga  headers 

5,  Indant 

-  oernanent 

•  temporary 

6,  Begin  next  page 

7,  Need  *  Unas 

9,  insert  t  blank  Unas 
9,  Cantar  the  next  #  Unas 
in.  Break 

11.  Define  a  eaero 

12.  Flll/Ne-f 111 

13.  Hyphanate/Mo-hyphanete 

14.  Under line 

15.  Seetlon/Chaeter  headings 

16.  Quotations 

17.  Footnotes 

is.  Keep  an  index 

19.  start  paragraph 

•  basic 

-  left  adjusted 

-  body  Indented 

-  numbered 

20.  start  display 

-  list 

-  block 

-  floating  block 

•  delayed  text 

21.  Table  handler  * 

•  definition 

-  start 

-  body 

•  and 

22.  Equation  definition 

23.  Multiple  column  format 

24.  Default  paper  formats 

•  thesis 

25.  Control  constructs 

•  read  special  variables 

•  change  special  register 

-  conditional  formatting 


*  part  of  Table  preprocessor 
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APPCNdlX  Et  DBASE  II 


DBASE  II  It  •  relational  database  system  created  by 
Ashton-Tate  of  bos  Angeles,  California  for  microcomputer 
systems.  For  this  review,  the  CP/M  version  of  DBASE  II  was 
used,  where  the  DBASE  II  program  is  an  executable  "command 
file"  residing  In  the  system. 

The  DBASE  II  system  utilizes  several  different  file 
typest  database,  report  form,  command,  index,  memory,  and 
text.  Each  file  tyoe  has  a  specific  purpose  that  is 
identifiable  by  its  type  name.  "Report  form"  files  store  the 
information,  specified  by  the  user,  for  deserlblno  the 
format  (headings,  fields,  totals,  subtotals,  contents,  etc.) 
in  which  a  "database"  file  is  to  be  output,  "Command"  files 
contain  a  seauence  of  0BA8E  II  statements,  commands,  and 
control  structures  necessary  to  create  a  user  defined  view, 
"Index"  files  are  a  list  of  pointers  to  a  soeelfle 
"database"  file.  "Memory"  files  contain  the  values  of 
memory  variables  and  constants  saved  previously  by  the  user. 
"Text"  files  are  collections  of  ASCII  characters  for  input 
into  a  "database"  file,  or  created  by  output  from  a 
"database"  file.  DBASE  II  cannot  directly  use  "text"  files. 
Most  of  the  files  are  stored  in  what  is  known  as  Standard 
Data  Format  (8DF),  and  they  can  be  used  dlreetly  by  any 
other  program  that  uses  30F  files.  Additionally,  any  text 
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The  file 


flits  In  SDP  can  be  used  by  the  DBASE  XI  system, 
is  the  largest  date  objeet  supported  by  DBASE  II  which 
creates#  deletes#  or  modifies  the  current  flle(s).  A 
database  file  Is  brouoht  Into  reference  by  user 
specification#  and  a  maximum  of  two  database  flies  can  be 
"open”  at  one  time. 

DBASE  IX  can  be  used  Interactively  or  can  be  programmed 
to  create  a  view  of  the  database  to  supoort  recurring 
applications.  Regardless  of  method#  DBASE  IX  provides  the 
user  with  the  same  basic  high-level  data  definition  (DDL) 
and  data  manipulation  (DML)  language.  An  English  like 
command  language  with  a  very  regular  syntax  Is  a  user 
friendly  feature  of  OBASE  IX.  The  commands  are  very 
powerful  In  that  their  ooerands  and  results  are  typically 
database  files.  The  command  structure  Is  usually  presented 
in  the  following  form! 

COMPAND  (SCOPE]  [CONDITION] 

The  scope  modifier  designates  the  number  of  records  to 
be  selected  In  response  to  the  soeelflc  command.  The 
condition  modifier  specifies  a  conditional  statement  that 
the  record's  field  values  must  satisfy  m  order  for  the 
record  to  be  included  In  the  final  result.  Table  E.l 
provides  a  listing  of  the  besic  DBASE  is  commands#  with 
duplicate  commands  having  been  factored  out. 


Tabic  E.l  -  DBASE  XX  Basle  Commands 


1.  Display  an  expression  on  the  seraan 

2.  Format  seraan  or  printar  output 

3.  Input  a  character  strino 

4.  Input  a  strino  to  a  memory  variable 

5.  bait  for  user  lnout 

6.  List  the  records  in  a  database 

7.  Display  data  from  a  database 

8.  Dlsolay  the  structure  of  a  database 

9.  Renem#  a  file 

10.  Erase  a  file 

11.  Generate  a  report 

12.  Execute  a  "command"  file 

13.  Return  from  a  "command"  file 

14.  Display  the  contents  of  the  memory  variables 
1$.  Store  a  value  in  a  memory  variable 

16.  Save  memory  variables  to  a  file 

17.  Restore  memory  variables  from  a  file 

19.  select  a  specific  database  for  use 

19.  Set  specific  DBASE  ri  parameters 

20.  Abort  a  command 


21.  Create  a  new  database 

22.  Edit  a  database 

23.  modify  a  database's  structure,  or  the 

contents  of  fields  in  selected  records 

24.  update  a  database  from  another  database 

25.  Add  data  from  a  text  file  to  a  database 

26.  Copy  data  from  a  database  to  a  text  file 

27.  Insert  reeord(s)  into  a  database 

28.  Delete  record(s)  from  a  database 

29.  Unmart  records  marked  for  deletion 

30.  Locate  a  reeord  based  on  key  value, 

or  condition 

31.  Goto  a  specified  reeord 

32.  Move  forward  or  backward  in  a  database 

33.  Index  a  database 

34.  Sort  a  database  based  on  a  field 

35.  Perform  JOIN  operation  on  two  databases 


36.  Count  tha  number  of  records 

37,  Sum  a  field  or  subfield  in  a  database 
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Default  ordering  for  record*  in  e  database  flit  is  the 
sequence  In  which  the  records  ere  entered.  Orderlnq  ean  be 
altered  by  lnsertlnc  records  into  specific  parts  of  the 
database,  and  by  sortlnq  or  Indexing  the  database,  in  the 
default  order#  the  "database"  file  does  not  contain  a 
recognised  bey. 

ay  sorting  or  indexing  a  "database"  file#  keys  ere 
defined  and  the  search  tine  required  to  loeate  a  record  is 
reduced,  multiple  indexing  be  done  for  the  same  database# 
but  based  on  different  keys.  Sorting  produces  a  new 
"database"  file#  whleh  is  a  copy  of  the  original  database# 
only  it  is  sorted.  An  "indexed"  file  is  a  virtual  file  of 
oolnters  to  the  original  "database"  file.  Whereas  lookup 
speed  ean  lie  enhanced  by  Indexing  a  database#  there  is 
overhead  incurred  in  maintenance  of  the  "index"  file. 
Changes  made  to  the  original  database  file  are  not  reflected 
in  the  new  sorted  "database"  or  "index"  file.  The  orioinal 
datebase  must  be  sorted  or  indexed  after  each  change  in 
order  to  remeln  current. 

The  date  definition  language  ellows  the  user  to  define 
the  organisation  of  the  date  in  a  new  database  file  by 
specifying  the  name  of  the  database#  and  giving  information 
on  each  of  its  fields  (name#  type#  width#  decimal  places). 
The  structure  of  a  new  database  file  ean  also  be  copied  from 
that  of  another  database  file.  Additionally#  new  structures 
can  be  created  as  the  result  of  using  the  join  operator 
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provided  by  the  DBASE  XI  system.  At  any  time#  the  structure 
•nd/or  contents  of  e  file  een  be  displayed  or  output.  The 
structure  of  e  database  file  een  also  be  modified  at  a  later 
time#  but  presents  some  problems  In  that  ell  records 
currently  in  the  database  file  are  destroyed. 

Besides  using  DBASE  XX  Interactively#  it  can  be 
programmed  In  Its  own  language  throuah  the  use  of  "command" 
flies.  The  omti  statements  are  embedded  In  the  file  and 
iterative  execution  of  DML  statements  are  controlled  by  a 
set  of  DBASE  II  control  structures  (If-Then#  If-Then-Else, 
Goto#  and  Do-While),  "Command”  files  tend  to  make  extensive 
use  of  memory  variables  and  Input/output  functions  which  are 
also  extensively  suoported  by  DBASE  II.  To  create  a  user 
vie*  the  desloner/proorammer  will  edit  a  "command"  flie(s) 

a 

to  contain  the  correct  DBASE  II  statements,  commands,  and 
control  structures  to  manipulate  the  oroper  "database” 
files.  The  capabilities  and  limitations  of  any  view  is 
dependent  on  the  deslon  of  the  "command"  flle(s). 

The  reeson  for  the  great  popularity  of  DBASE  XX  Is  that 
It  is  a  very  eesy  database  management  system  to  learn  and 
use.  Its  Engllsh-like  command  language  is  natural  and  user 
friendly.  Although  the  command  set  Is  rather  extensive#  the 
commend  names  accurately  describe  their  action  and  use  e 
regular  syntax  so  they  are  easy  to  remember.  The 
lnterectlve  nature  and  full  screen  display  orientation  makes 
user  interaction  simple  and  dlreet.  with  its  set  of 


predefined  functions#  input/output  commends,  "commend" 
files#  end  programming  constructs  it  is  easy  to  ereete  views 
for  elmost  eny  epolleetion,  DBASE  XI  is  e  powerful 
reletlonel  detebese  system  yet  it  is  obvious  thet  the 
designers  geve  much  thought  to  weeping  it  simple  end  did  not 
introduce  comolexlty  for  its  own  sake,  However#  there  ere  e 
couple  of  problems  with  DBASE  XT  which  ere  worth  mentioning, 
end  they  ere  ell  probebly  due  to  the  justified  emphesls  on 
simplicity. 

(1)  At  eny  one  time#  e  meximum  of  two  detebeses  cen  be 
In  reference.  This  llmltetion  requires  tnet  detebeses  be 
explicitly  brought  Into  end  out  of  use.  It  would  helo  it 
there  was  another  method#  besides  using  a  "commend"  file, 
for  performing  operetlons  on  multiple  tables. 

C2J  In  modifying  the  structure  of  a  database  the 
contents  ere  deleted.  This  requires  that  the  database  be 
explicitly  saved  to  an  external  detebese  and  then  be 
recopled  baew  after  structure  modification.  It  Is  an 
inconvenience,  to  say  the  least. 

(I)  The  only  relational  operation  directly  provided  by 
the  system  is  the  JOIN  command.  Xt  would  greatly  enhance  the 
capability  of  the  system  to  provide  more  of  the  operators. 

(4)  The  display  structure  is  a  little  bit  too  rigid# 
and  the  user  does  not  novo  much  direct  control#  sort  of 
writing  a  "command"  file#  to  offset  the  output  format. 
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APPENDIX  F:  SEQUITUR 

SEQUITUR  &•  •  relational  database  system  designed  by  the 
Pacific  software  manufacturing  Company  of  Berkeley* 
California. 

SEQUITUR  sees  a  database  as  a  collection  of  named 
tables*  each  of  which  contains  some  kind  of  data  related  to 
the  subject  of  the  database.  Each  database  has  a  set  of 
system  tables.  The  "Column"  table  lists  the  name*  type, 
size*  and  display  format  of  all  columns  authorized  for  use 
In  the  database's  tables.  The  "Table"  table  lists  the  names 
of  the  columns  that  are  included  In  each  of  the  database's 
tables.  Together  the  "Column"  and  "Table"  tables  act  as 
oart  of  a  data  dictionary  system  for  the  database. 

SEQUITUR  has  a  fairly  large  command  vocabulary  of  over 
sixty  seven  commands.  There  are  twenty  five  basic  commands* 
forty  two  screen  editor  commands*  and  more  formed  by 
combinations  of  the  previous  commands.  A  multilevel  "Help" 
facility  Is  used  to  supoort  the  user. 

SEQUITUR  offers  four  kinds  of  help.  There  are  status 
lines  et  the  toe  of  the  screen.  An  "edit  card"  display  can 
be  called  by  the  user  in  order  to  see  a  comprehensive  list 
of  cursor  object  and  motion  keys*  and  escape  operations. 
The  "help"  commend  summons  an  on«llne  manual*  that  Is  preset 
by  the  user  to  provide  no*  medium*  or  maximum  help.  Lastly* 
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there  arc  situational  help  prompts  that  occur  during  the 
command  proeass. 


Table  F.l  -  SEQUITUR  Basle  Commands. 


1.  CHOOSE  (database) 

2.  CREATE  {database) 

3.  40D  to  {table) 

4.  EDIT  (table) 

5.  show  {table) 

6.  PRINT  {table) 

7.  REPORT  generator 
S.  FORMS  generator 

9.  SELECT  from  (table)  * 

10.  MANUAL  select 

11.  JOIN  (tables) 

12.  SORT  (tables)  * 

13.  UNION  * 

14.  INTERSECTION  * 


15.  DIFFERENCE  * 

16.  UNIQUE  rows  * 

17.  DUPLICATE  rows  * 

18.  COPT 

19.  APPEND 

20.  REMOVE  rows 

21.  rename  column 


22.  COMPACT  base 

23.  OUMP  to  (file) 

24.  LOAD  from  (file) 

25.  HELP  from  manual 

26.  EXIT 


*  •  Member  of  SEQUXTUR's 

"set”  commands. 


The  twenty  five  basic  commands  cover  tne  major 
operational  capabilities  of  the  SCQUITUR  system.  The 
commends  are  oresented  to  the  user  in  tne  form  of  a  menu. 
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•nd  one*  a  choice  Is  made  SEQUXTUR  enters  the  display  mode 
necessary  to  support  that  eholee.  Table  P,1  lists  the  basic 
commands,  plus  the  command  for  exiting  from  SEQUXTUR, 

The  SEQUXTUR  display  modes  are  organized  as  "tables",  or 
"paoes*.  The  table  mode  is  similar  to  the  approach  taKen  by 
the  "Queryby-Example"  system  (QBE),  and  Presents  the  data 
in  columns  and  rows  with  vertical  lines  separating  the 
columns  and  Indicators  for  new  rows.  Alternatively,  the 
page  mode  presents  the  data  one  row  at  a  time,  with  the 
column  headlnas  listed  vertically*  The  user  has  the  ability 
to  flip  back  and  forth  between  the  two  display  modes  at 
will. 


Table  P.2  -  SEQUXTUR  Cursor  Object  &  Motion  Commands. 


1.  Move  cursor  up  one  line 

2.  Move  cursor  down  one  line 

3.  Move  cursor  left  one  objeet 

4.  Move  cursor  to  next  objeet 

5.  Move  cursor  to  beginning  of  object 

6.  Move  cursor  to  previous  word 

7.  Move  eursor  to  end  of  current  objeet 

8.  Move  cursor  to  next  word 

9.  Object  a  word 

10.  Object  a  line 

11.  Objeet  a  sentence 

12.  Objeet  a  paragraph 

13.  Object  a  view 

14.  Objeet  a  page  or  sereen 

15.  Objeet  a  column 

is.  Object  a  row 

17.  Object  *  one  character 


One*  in  a  desired  display  aeda  tha  uaar  must  aaiea  us*  of 
the  adltor  eoaaands  to  oak*  change*  to  tha  tabla.  All  editor 


eoaaands  ara  single  keys  combined  with  tha  <Control>» 
<Eseae«>.  or  <Tab>  keys.  Table  r.2  provides  a  list  of  the 
cursor  object  and  notion  eoanands  available.  Most 
operations  require  two  eoaaands  since  the  object  oust  be 
specified  first,  and  then  the  aetual  operation. 


Table  p,3  -  sequitur  Screen  Editor  Commands. 


1. 

2. 

3. 

4. 
*. 
«. 

7. 

8. 

9. 

10. 
11. 
12. 

13. 

14. 


Delete  left  portion  of  object 
Delete  entire  objeet 
Delete  right  portion  of  object 
nips  "insert"  toggle 
Shoes  roes  marked  for  deletion 
Flip  "paae-table"  display  style 
Roto  S-th  object 
Goto  last  objeet 

Restores  more  recent  version  of  row 
Display  earlier  version  of  row 
Executes  a  command 
search  forward  for  column  entry 
Search  backwards  for  column  entry 
Edit  card  display 


The  screen  editor  commands  are  used  to  make  actual 
changes  (additions,  modifications,  or  deletions)  to  the 
displayed  table  on  the  screen.  Table  E.3  lists  these 
commands  which  are  used  In  conjunction  with  the  eursor 
object  and  movement  commands  listed  previously. 
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Additionally  there  or*  •  number  of  miscellaneous 
commands  that  ara  provided  to  aid  the  user.  These  are  listed 
in  Table  F.4. 


Table  F.4  •  Additional  SEQUXTUR  Commands 


1.  Get  Edit  Help 

2.  Scroll  Forward 

3.  Scroll  Backwards 

4.  Interrupt  Present  operation 

5.  Loek/Unloek  Cursor  Object 


There  are  an  abundance  of  table  types  in  SEOUITUR. 
"Virtual"  tables  consist  of  pointers  to  data  In  a  "base" 
tablets),  and  are  formed  by  conducting  relational  operations 
(e.o.  JOIN)  on  the  base  tablets).  virtual  tables  are 
permanent  additions  to  the  database.  All  operations 
conducted  on  the  virtual  table  effect  the  base  table,  but 
not  all  operations  on  the  base  table  will  refleeted  in  the 
virtual  table. 

"Sllee"  tables  eonslst  of  the  data  from  a  "home”  table, 
and  are  formed  by  restricting  or  rearranging  the  columns  In 
the  home  table.  Actually,  sllee  tables  are  just  alternate 
ways  of  viewing  the  same  home  table.  All  operations 
conducted  on  the  sllee  table  effect  the  home  table,  and  all 
operations  on  the  homo  table  effect  the  sllee  table. 
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"Template"  tables  ars  used  to  stera  control  information 
on  tna  oparatlon(s)  (SELECT,  SORT,  union,  duplicate,  unique, 
INTERSECTION,  and  DIFFERENCE)  desired  to  be  performed  on  a 
set  of  "base"  tables.  The  user  specifies  once  the  sequence 
of  operations  to  be  performed,  and  eaeh  time  that  result  is 
desired  the  appropriate  template  table  Is  ealied  to  create 
the  desired  virtual  table. 

'  SEQUITUR  provides  several  methods  of  outputting  data  to 
the  user: 

(1)  There  is  the  "print”  command  which  prompts  the  user 
to  specify  headlno,  page  length,  margins,  page  number,  date, 
column/row  divider  symbol,  ete.  for  either  a  "table"  or 
"oage"  style  output.  The  entire  table  Is  then  output,  one 
record  at  a  time,  in  the  specified  format. 

(2)  There  is  the  "form  generator".  The  user  creates  a 
form  latter  or  document  by  maxing  an  entry  In  the  "forms" 
table  in  either  "page"  or  "table"  style,  and  answering 
several  system  prompts  as  to  page  slse,  width,  margins.  The 
form  generator  Is  Intended  for  letter  type  generation  since 
it  only  allows  one  text  field  In  the  form.  Ail  other  entries 
are  pulled  from  an  appropriate  table  and  the  "form"  repeated 
for  each  row  In  that  table. 

(3)  There  is  the  "report  generator”.  The  user  creates  a 
report  table  that  Is  associated  with  a  known  data  table.  The 
report  table  specifies  vhleh  data  table  columns  are  to  be 
used,  hew  they  are  positioned,  what  name  they  have  on  the 


fern,  allotted  width,  and  alignment.  Again,  the  user  must 
spaeify  formatting  items  UKe  page  length,  line  length, 
margins,  delimiters,  and  other  related  items.  The  individual 
columns  in  the  report  table  ean  be  marked  for  sorting, 
grouping,  and/or  arithmetic  proeesslno.  Zf  arithmetic 
processing  is  opted  for,  then  another  table,  the  "function” 
table  is  created  to  reeord  what  is  to  be  done  to  each  column 
*  total,  minimum,  maximum,  average,  or  count. 

Based  on  a  very  short  familiarization  experience  with 
SEQUITUR  there  is  no  doubt  that  it  is  a  powerful  and 
complete  relational  DBMS,  However,  it  is  not  as  user 
friendly  as  its  advertisements  would  lead  you  to  believe. 
Seme  of  the  problems  encountered  were* 

(1)  Too  many  commands  to  remember.  This  increased 
learning  time  and  added  to  the  confusion.  Too  many  of  the 
commands  were  just  window  dressing  in  that  their  effect 
could  have  be  done  using  other  commands,  (Like  the  "Object 
a”,  extra  cursor  movement  and  deletion  commands.)  while 
using  keys  as  commands  leads  to  faster  command  input,  it 
makes  things  more  difficult  when  there  are  so  many  commands 
the  symbol  on  the  key  has  little  or  no  relation  to  its 
effect, 

(2)  The  structure  of  the  user  interface  was  unwieldy.  It 
was  easy  to  gat  lost  and  difficult  to  recover  to  a  known 
location.  Operations  that  worked  under  one  condition  did 
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not  work  In  anothar*  or  produced  completely  di£f«r«nt  and 
unexpected  results.  Ce.g,  In  soaa  lnstaneaa  tna  "execute* 
eomaand  will  raturn  you  to  tha  main  manu,  in  othara  It  vas 
Ignored  or  traatad  aa  a  mistake.) 

(3)  Thara  were  too  aanv  tvoaa  of  tables,  says  of  using 
tables,  cdltlno  tablaa,  and  creating  raiatlona  between 
tablaa.  The  uaar  la  being  swamped  with  a  leval  of  detail 
tnat  la  better  left  to  the  system.  It  seems  that  scquitur 
was  created  with  simplicity  and  user  suooort  being  lesser 
considerations  to  system  sophistication. 


APPENDIX  Gt  VI8ICALC 


VISICAIC  Is  an  electronic  spreadsheet  prooraa  created  by 
Software  Arte,  Inc,  of  Cambridge,  Massachusetts  and  marketed 
by  Personal  Software  Ine.  of  Sunnyvale,  CA,  Its  purpose  Is 
to  allow  the  user  to  easily  model  a  wide  ranoe  of  numerical 
problems  In  a  standard  tabular  format  by  replacing  the 
user's  oencll,  calculator,  and  scratchpad. 

The  screen  Is  divided  Into  a  grid  of  columns  and  rows 
that  form  addressable  (column,  row)  entry  positions.  The 
columns,  which  run  across  the  top  of  the  grid,  are  lettered 
starting  with  "A"  and  the  rows,  which  run  down  the  side,  are 
numbered  starting  with  "l".  Each  entry  position  is  an 
lndeeendent  entity,  and  can  contain  a  character  string,  a 
numeric  value,  or  a  function  that  must  be  calculated.  Entry 
positions  that  contain  functions  are  recalculated  by 
VISICALC  each  time  certain  conditions  are  net.  The  functions 
will  specify  values  In  terms  of  constants,  operators,  and 
the  values  of  other  entry  positions. 

The  screen  Is  used  as  a  "window"  into  the  spreadsheet 
and  Is  modifiable  by  the  user.  The  user  Is  given  numerous 
commands,  see  Table  6.1,  with  which  to  alter  the  dlsoiay 
format  of  the  screen. 


Table  6.1  -  VXSXCALC  Display  Coaaands. 


1.  Clear  Spread  Sheet 

2.  Set  Global  Display  Poraat  Toy 

-  Integer 

•  Dollars  a  Cents 

-  Left/Right  Justified 

-  Graph 

3.  Set  Entry  Display  Pormat  To; 

-  integer 

-  Oollers  &  Cents 

•  Left/fight  Justified 

-  Graph 

4.  Reset  Entry  To  Global  Display  Pornat 

5.  Set  Column  width  within  A  window 

6.  set  Order  Of  Recalculation; 

-  Column  Wise 

•  Row  wise 

7.  set  Receleulatlon; 

-  Automatic 

•  Manual 

8 •  Move  An  Entire  Row  Or  Column 

9.  window  Control! 

•  split  Screen  Horizontal 

•  split  Sereen  vertical 

•  Single  window 

10,  window  Synchronization; 

•  Synchronized 

-  unsynchronized 


The  window  can  be  "split"  into  two  halves  so  as  to  look 
into  nonadjoining  areas  of  the  spreadsheet  simultaneously. 
The  two  windows  ean  be  "synchronized”  so  they  move  together, 
or  unsynenronised  so  movement  is  independent.  Display 
format  may  be  globally  set  for  the  sereen  as  a  whole,  or 
individual  entry  positions  ean  be  assigned  their  own  format. 
Column  width  is  variable  from  3  to  37.  but  columns  in  the 
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same  window  oust  novo  the  same  width.  Tho  valuo  of  ooeh 
•ntry  position  Is  esleulotod  by  "column  order*  (Mf  AS.  ..., 
An,  Bt,  B2,  ...,  Bn,  Cl,  etc.)  unless  the  user  changes  the 
recalculation  order  to  "row  order”  (Ai,  Bl,  ....  ni,  as,  B2, 
...,  n2,  C2 ,  etc.).  By  default  VXBXCALC  starts  In 
"automatic”  recalculation  node  where  the  value  of  all  entry 
positions  are  recalculated  each  tine  an  entry  Is  changed.  As 
this  can  significantly  slow  down  the  model  when  laroe  grids 
and/or  complicated  numerical  expressions  are  used,  the  user 
can  enter  "manual”  recalculation  node  where  a  command  must 
be  issued  to  eause  recalculation  to  oeeur. 

VISICALC  provides  a  command-line  oriented  editor  that 
enters,  modifies,  or  deletes  data  In  a  referenced  entry 
oosltlon(s).  a  cursor  Is  provided  on  the  grid  to  Indicate 
the  current  entry  position  referenced  by  VTSICALC.  There 
are  sereen  commands  to  allow  the  user  to  scroll  across  the 
grid  or  to  move  to  an  exact  (row,  column)  entry  position. 
Zf  needed,  the  numeric  processing  capability  of  VTSXCALC  can 
be  used  like  a  calculator  to  support  the  user's 
computational  needs.  A  powerful  capability  of  VZBXCALC  Is 
the  replleate  command.  This  allows  the  user  to  define  an 
entry  onee,  and  then  have  It  entered  m  a  range  of 
successive  eolumn  or  row  entry  positions.  Additionally,  the 
user  can  specify  If  the  original  entry  Is  to  be  replicated 
exactly,  or  should  any  references  to  other  entry  positions 
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be  updated  at  each  new  petition  to  ta((o  into  aeeount 


relative  petition  on  the  spreadsheet. 


Table  e.2  •  visicalc  carter  movement  A  Entry  Coeeandt. 


li«  Move  Carter  Right  or  up 

12.  Move  Carter  Left  Or  Down 

13.  Change  Carter  oireetleni 

-  Up/Dewn 
•  eleht/Left 

14.  Move  Carter  To  The  Other  window 

15.  neve  Cursor  To  A  Specific  Entry  position 


it.  Abort  Lett  Contend 

17.  set  An  Entry  Position  To  Blank 

is.  Delete  An  Entire  Pow  Or  Column 

19.  Inset  A  New  Now  Or  Column 

20.  Replleate  An  Entry 

21.  set  Title  Areas » 

-  Horlsontal  Title 

-  vertical  Title 

-  No  Title 

22.  Repeat  A  Label  Ent*  $ 

23.  wake  An  immediate  Numerical  Calculation 

24.  Enter  A  Label  In  An  Entry  Position 

25.  Enter  A  value  In  An  Entry  Position 
2S.  Save  A  Copy  Of  The  Spread-Sheet 


Since  VISICALC  it  a  numerical  modeling  tool  it  hat  a 
series  of  arithmetic  and  aggregate  functions  that  it 
sapporta.  Table  S.3  provides  a  listing.  VISICALC  hat  been 
designed  to  store  numbers  in  decimal  format,  not  binary,  and 
maintains  them  with  up  to  eleven  significant  digits  or 
decimal  places. 


Table  (3.3  •  VXSXCALC  Arithmetic  &  Aggregate  Functions 


a.  Addition 

b.  Subtraction 

c.  Multiplication 

d.  Division 

e.  exponentiation 

f.  Calculate  The  Sun  Of  A  Range  Of  values 

g.  Calculate  The  Minimum  in  A  Range  Of  Values 

h.  Calculate  The  Maximum  In  A  Ranee  Of  values 
1.  Count  The  Number  Of  entries  In  A  List 

1,  Calculate  The  Average  Of  A  Range  Of  values 

k,  Calculate  The  Net-Present-Value  Of  A 

Range  Of  Values 

l,  Perform  A  Lookup  Operation 
n,  PI  (3.1415936S36) 

n.  Calculate  The  Absolute  value 

o.  Calculate  The  integer  Portion  Of  A  value 
o.  square  Root 

g.  Logarithms,  Base  3 

r.  Logarithms,  Base  10 

s,  Trloonometrle  Functions  (Sin,  Cos,  Tan,  Asln, 

acos,  Atan) 


VXSXCALC  makes  use  of  dynamic  memory  allocation  so  the 
actual  dimensions  of  the  spreadsheet  depend  on  the  amount 
of  memory  evallable  and  the  complexity  of  the  entries  made 
by  the  user.  The  user  does  not  have  to  worry  about  memory 
allocation  since  VXSXCALC  takes  responsibility  for  Its  use 
and  efficiency.  As  entries  shrink,  or  are  deleted,  VXSXCALC 
reclaims  the  extra  memory  space.  The  user  is  shown  how  much 
memory  remains  and  a  warning  prompt  occurs  when  memory  space 
is  nearly  exhoested. 


r or  a  permanent  eepy  of  tho  contents  of  the  spread  sheet 
the  user  nay  send  the  output  to  e  printer,  a  suboart  of  the 
total  spreadsheet  nay  be  sent  by  designating  the  lower 
right  corner  to  be  printed. 

VX3ICALC  Is  a  powerful  and  fairly  simple  modeling  tool 
whose  advantages  seen  to  easily  outweigh  the  disadvantages. 
The  command  vocabulary  Is  low  C?6  commands,  19  functions) 
and  the  greater  majority  are  actually  useful  and  not  just 
window  dressing.  The  user  manual  is  well  written  and  easily 
understood,  but  Is  fairly  Iona.  VISXCALC  supports  a  Known 
human  weakness  (small/fast  short  term  memory,  laroe/slow 
lono  term  memory,  and  slow  calculation  speed)  by  remembering 
the  details  of  a  eommonlv  reoccurrlng  user  problem  (the 
situation  to  be  modeled),  llmitlna  the  user  to  providing  a 
smaller  and  more  select  set  of  initial  Inputs,  and 
oerformlng  the  computations  in  a  taster,  more  reliable,  and 
repeatable  manner.  However  It  does  have  some  problems i 

(1)  Command  strings  and  their  effeet  must  be  memorized 
since  there  Is  little  relation  to  the  string  and  the  effeet. 
menus  provided  by  the  system  ere  very  poor,  and  require  you 
to  already  knew  the  meaning  of  the  commend  string. 

(3)  a  basic  understanding  of  YXSXCAbC  and  a  high  degree 
of  operational  capability  ean  be  obtained,  in  a  fairly  short 
time,  by  reeding  only  the  first  third  of  the  user  manual. 
However,  to  gem  maximum  use  of  the  system  requires  a 
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significant  amount  of  tlna  and  effort  to  road  the  antlra 
user  manual  and  experiment  with  the  oparatlona.  some  nlea  to 
Know  features  that  have  a  major  effect  on  model  validity 
(e,g,  recalculation  order)  are  discussed  at  the  end  of  the 
user  manual  and  night  be  easily  mlssad. 
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APPENDIX  Ht  ZIP 


The  relational  data  baae  management  system  "DBASE  II" , 
daaerlbad  in  Appendix  (D),  eontalna  a  sat  of  commands  which, 
when  embedded  in  a  "command"  file,  define  the  output  format 
used  to  generate  the  display  on  tha  screen,  or  output  to  the 
printer.  In  addition  to  aenerating  the  display  form,  the 
commands  also  direct  the  DBASE  II  system  to  either  determine 
the  values  of  the  entries  from  a  record  In  the  referenced 
database,  or  from  memory  variables.  If  the  Input  device  Is 
the  screen/keyboard,  DBASE  II  may  retrieve  a  user  entered 
value  from  the  screen  and  store  it  in  a  field  of  a  database 


record,  or  In  a  memory  variable.  These  form  definition 
commands  can  also  be  put  into  a  new  tyoe  of  file,  the 
"format"  file,  by  ZIP,  In  this  ease  the  format,  contained 
in  the  "format"  file.  Is  used  as  an  display  overlay  to 
prompt  the  user  to  change  data  values  In  an  exlstlno  record 
in  a  "database"  file. 

ZIP  Is  a  CP/m  program  used  to  generate,  or  modify,  a 
DBASE  II  "command"  or  "format”  file.  It  is  a  powerful  tool 
In  the  sense  that  the  user  Is  not  regulred  to  know  the 
details  of  tha  DBASE  II  form  genaratlon  capability 
("command"  files,  and  display  commands).  ZIP  presents  the 
user  with  a  blank  screan  and  an  on»sereen  editor,  which 
supports  several  levels  of  cursor  movement  and  formatting 
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command*,  to  help  In  the  form  design.  Table  H,i  lists  the 
ZIP  editor  commands. 


Table  H,  1  -  ZIP  Editor  Commands, 


1.  Screen  commands 

-  top 

-  bottom 

-  next 

-  orevlous 

•  first 

•  last 

2.  Piddle  of  line 

3.  Insert  a  space 

4.  Add  a  line 

5.  Palate 

-  character 

-  line 

6.  Praw/Erase  horizontal  line 

7.  Draw/Erase  vertical  line 

8.  Erase/Save  work  file 

9.  Insert  DBASE  II  command  expression 

10.  Chanae  variable 

-  vertical  marker 

-  horizontal  marker 

-  tab  spaclnq 

•  margin 

-  oace  length 

11.  Quit 


The  eursor  can  be  moved  to  any  position  on  tho  blank  screen 
where  the  user  will  enter  the  information  required  by  the 
ZIP  prooram,  information  is  conveniently  limited  to  literal 
strings,  memory  variables,  record  field  values,  and  fetching 
a  value  from  tho  sereon  and  storing  it  into  a  record  field 
or  memory  variable.  Interspersed  between  thoso  ZIP 
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formatting  commands  may  be  DBASE  XX  executable  commands  if 
the  fil#  typ#  la  "command".  There  are  special  purpose 
commands  to  draw,  or  undraw,  vertical  and  horizontal  lines 
on  the  form. 

The  EXP  program  nay  be  viewed  as  a  translator  between 
the  screen  design  made  by  the  user  and  the  operations  of 
DBASE  IT.  The  screen  contents  associated  with  each  screen 
oosltlon  are  translated  Into  a  sequence  of  DBASE  XI 
commands,  statements,  and  control  structures  which  are 
organized  as  either  a  "command"  or  "format”  file,  ZIP  also 
places  any  embedded  execution  commands  into  the  file  and 
automatically  sets,  or  resets,  the  aoproorlate  system 
"toogies"  as  needed. 

ZXP  is  a  useful  support  tool  for  DBASE  il  in  that  It 
relieves  the  user  from  having  to  program  a  "command"  file  In 
order  to  create  a  desired  display  format.  However,  It  must 
be  pointed  out  that  ZIP  Is  a  very  basic  formatter.  Is  line 
oriented,  and  is  incapable  of  the  more  complex  types  of 
displays. 
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APPENDIX  It  MAIL 


"MAIL”  is  an  electronic  nail  facility  produced  by  the 
University  of  California  at  Berieeley  and  Bell  Laboratories 
for  the  UNIX  operatlnc  systen.  It  allows  users  to  send 
nessaoes  to  other  users,  or  croups  of  users,  on  the  system. 

The  basic  unit  of  the  NAIL  system  Is  the  message,  which 
is  simply  a  special  type  of  text  file.  The  messaqe  Is 
preformatted  and  contains  fields  for  originator, 
destination,  subject,  copy  to,  and  body,  messages  are 
contained  either  in  the  users  "private"  mailbox  or  in  the 
"system”  mailbox.  A  "dead-letter”  file  is  also  maintained 
for  each  user  to  eontaln  messages  which  cannot  be  delivered 
to  a  valid  destination.  The  private  mailbox  and  dead-letter 
file  are  maintained  as  text  files  In  the  UNIX  directory  and 
therefore  can  ba  used  by  other  programs  running  under  Unix. 

upon  logging  Into  the  UNIX  system,  a  prompt  appears  at 
the  terminal  Indicating  that  there  Is  mall  for  the  user. 
Messages  addressed  to  a  user  are  initially  contained  in  the 
system  mailbox,  and  can  be  read  from  the  system  mailbox  by 
the  MAIL  facility.  The  messages  already  In  the  private 
mailbox  and/or  dead-letter  file  are  text  flies  and  thus  not 
directly  accessible  to  the  MAIL  facility. 

The  user  may  eleet  to  read  the  mail  by  invoking  the  mail 
facility.  A  ana  line  summary  of  all  messages  in  the  system 
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Mailbox  li  presented  to  tho  user,  tnd  ooeh  message  is  given 
on  Integer  idontif leotlon  number  storting  ot  one,  At  this 
point  tho  uior  hoi  o  nunbor  ot  different  options  ovolloblo 
os  suMMorlzod  in  Toble  1.1. 


Toblo  1.1  •  MAIL  Conmond  sunmory 


1.  Alios  o  nono  + 

2.  Unsiios  o  noaels) 

3.  Soto  orovlous  mossogo  *  ♦ 

4.  Soto  noxt  message  *  ♦ 

5.  Display  suonory  ot  eommonds  ♦ 

$,  Oisploy  out  oil  eurrontly  dotinod  ollosos 

7.  Display  o  mossogo 

8.  Display  out  hoadors  ot  mossogo  list  ♦ 

9.  Display  mossogo  list 

10.  Oisploy  size  ot  ooch  mossogo 

11.  Display  top  tow  linos  ot  ooeh  mossogo 

12.  execute  tho  following  UNIX  shell  command 

13.  Chance  directory 

14.  Oolete  messaged)  ♦ 

15.  Delete  current  mossogo#  print  noxt  mossogo 

16.  Undelete  messages  marked  for  deletion 

17.  Poplv  to  o  received  message  * 

18.  Edit  o  list  of  messages  in  turn 

19.  Send  mossogo  to  designated  users  + 

20.  End«of •message  ♦ 

21.  Exit#  don't  change  system  mailbox  * 

22.  Quit,  save  undeleted  or  unsaved  messages  in  the 

user's  mailbox,  save  unreferenced  in  the 
system  mailbox. 

23.  Marx  messoge(s)  to  be  saved  in  system  mailbox  * 

24.  Save  a  message  list  by  appending  to  a  text  file  * 
29.  List  current  ranee  of  message  headers 

26.  Help  v 

27.  Set  options  ♦ 
if.  Unset  options 


«  mail  facility  has  more  than  one  command  to 
perform  this  action. 


♦  Useful  •  see  page  170,  paragraph  (2). 


The  user  may  select  a  massage  and  read  It.  After 
reviewing  the  message  the  user  nay  forget  the  message/  save 
It  in  the  system  mailbox,  delete  It,  or  prepare  a  response, 
when  the  user  oults  the  mail  facility  all  messages  whleh 
have  not  been  deleted,  saved,  or  reviewed  are  plaeed  back 
into  the  system  mailbox.  The  remaining  messages,  those 
reviewed  but  no  special  action  indicated,  are  placed  in  tne 
private  mailbox.  If  the  user  desires,  the  mail  facility  ean 
be  exited  and  the  system  mailbox  left  unchanged. 
Additionally  the  user  ean  create  "alias"  names  that 
correspond  to  multiple  users,  ask  for  message  summaries, 
append  messages  to  files,  or  invoke  an  editor. 

The  MAIL  utility  does  not  contain  its  own  editor,  but 
depends  on  the  edltor(s)  available  to  the  Unix  system  and  on 
the  user  to  set  an  option  specifying  which  one  is  desired. 
When  the  user  indicates  that  a  message  is  to  be  created,  the 
editor  is  invoked,  the  user  enters  the  text,  and  when 
finished  issues  an  end*of«message  command  to  return  control 
to  the  mail  facility,  while  in  the  editor,  the  user  ean 
issue  "escape"  commands  that  dlreetly  effect  the  message 
processing.  A  listing  of  these  eseapo  commands  is  provided 
in  Table  1.2.  Contents  of  other  files  may  be  inserted  into 
the  message,  names  of  recipients  added  or  changed,  the 
header  field  edited,  or  an  alternate  editor  invoked. 


Table  X.2  -  MAI 


in< 


1.  Execute  UNIX  shell  coeeend 

2,  Add  names  to  recipients  of  copy 

3.  Meed  "deedletter"  file  Into  message 

4,  Invoice  text  editor 

s.  Abort  the  message  be Inc  sent 

6.  Insert  e  neeed  file  into  the  eessepe  ♦ 

7.  Creete  e  subject  field 

o.  write  the  message  into  e  neeed  file 

Mine  the  message  through  «  process  es  e  filter 
10.  Insert  e  string  into  the  message 


♦  Useful  -  see  page  170,  paragraph  (2). 


while  In  the  mail  facility,  UNIX  shell  eoeeands  nay  be 
issued.  The  MAIL  facility  Is  temporarily  interrupted,  the 
command  is  executed,  and  then  the  “AIL  facility  Is  resumed 
without  adverse  effeet. 


Table  1.3  •  NAIL  options. 


1.  (Append/Prepended}  messages  to  private  mailbox 

2.  CYes/wo)  Subject  lino  prompt 

3.  (Yes/wo)  Prompt  for  carbon  eopy  recipients  of  message 

4.  (Yes/ wo)  Modify  delete  command 

5.  (Yes/Me)  Ignore  terminal  interrupt  signals 

••  (Yes/wo)  include  sender  In  group  message  recipients 

7.  cres/we)  Saving  interrupted  messages 

s.  Define  default  editor  nemo 

9.  Define  escape  character 

to.  Define  file  to  record  outgoing  mall 

11.  Oaf me  number  of  lines  In  the  "top”  of  a  message 
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Additionally,  the  MAIL  facility  hat  a  stria*  of  options 
the  usar  can  change  to  tailor  Its  operation.  Table  1,3 
provides  a  listing  of  these  options. 

The  MAIL  facility  is  a  good  support  program  and  Is  gulta 
capable  of  accomplishing  Its  coals.  However,  It  has  more 
than  Its  fair  share  of  problems, 

(1)  There  is  a  very  limited  user  manual,  and  experience 
must  be  gained  from  other  users  or  by  trial  and  error. 

(?)  There  are  too  many  commands,  and  too  many  of  those 
duplicate  each  other.  The  number  of  commonly  useful 
commands  Is  lav  (marked  with  a  ♦  ),  with  the  rest  being 
window-dressing, 

(3)  The  facility  Is  not  user  friendly.  The  user  must  be 
aware  of  location  In  the  facility  end  what  is  expected  next, 
because  there  are  no  soeclal  prompts  and  the  help  command 
only  provides  a  command  summary, 

(4)  If  the  message  recipient  Is  on  line  when  the  message 
arrives,  whatever  operation  Is  In  progress  Is  rudely 
Interrupted  by  the  dlselay  of  the  message.  This  can  be  vary 
disconcerting  to  the  recipient, 

(5)  The  user  can't  determine  whleh  message  Is  going 
where  (system  mailbox,  private  mailbox,  dead-letter  file), 
prior  to  leevlng  the  mail  facility. 
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